# Reporting incorrect data > How to report a wrong posting so we can actually fix it, what we can and can't correct, and the removal path if you're named in one. Source: https://hyperjobs.io/help/data-corrections Send us the **job id** and what's wrong with it, to . That's the whole procedure, and a concrete example is worth far more to us than a general report — "your salaries are often wrong" isn't actionable; one id with a mis-parsed salary is. ## What to include ``` id: ashby:7c1f2a94-… field: salary.annual_max we say: 240000 actually: 140000 (the posting says "$120k–140k") ``` The `id` is the part we genuinely need — everything else is us guessing which posting you meant. If it's a filter returning something odd rather than one bad row, include the full request URL with your key redacted. Support will never ask for it, and there's nothing we could do with it that we can't already do from your account. If you've pasted a key into a ticket or a screenshot, [revoke it](/help/api-keys). ## What we can fix **Enrichment errors** — the derived fields — are the fixable category, and the one most worth reporting: - A mis-parsed salary, or a salary attached to the wrong currency or period - A wrong `seniority` - A missing or wrong skill - A wrong taxonomy or location These come from classifiers, and classifiers are wrong sometimes. Coverage varies by field, and [coverage](/docs/reference/coverage) is honest about where it's thin — a `null` salary usually means "not stated in the posting", not a bug. ## What we can't fix **The employer's own posting.** Title, description, and `apply_url` are mirrored from the company's ATS board. If the employer wrote the wrong salary or a stale job description, our copy faithfully reproduces their mistake. We don't edit employers' postings — that would make the data wrong in a different, worse way. Ask the employer. **A job that 404s.** That's not incorrect data; that's the posting being taken down or collapsed as a duplicate. See [where the data comes from](/help/data-sources). **A job that "should" be there and isn't.** Usually one of two things: the board isn't one we track, or a filter is narrower than you think. Invalid values [return a `400`](/docs/errors) naming the parameter, so start from the error if you got one — otherwise check [filtering](/docs/guides/filtering) (comma = OR, except `skill`) before reporting it. If it's a board we don't cover, tell us which company and which ATS; that's useful. ## If you're named in a posting Sometimes an employer writes a person into a job ad — "reports to Jane Smith, VP Engineering", a named hiring manager, a recruiter's email. We didn't ask for it and don't want it, but if the employer published it, our copy of the posting contains it. You can have it removed. Email with a link to the posting or its job id, and tell us which part is about you. You don't need to prove a legal basis or make an argument. Ask, and we remove it from the dataset. What we **can't** do is take it off the employer's own board — we don't control that page. If the posting is still live there, ask the employer too, or our copy may reappear on a later crawl. Tell us and we'll suppress the id so it doesn't. The reasoning behind all of this — why postings are mostly company data, what we deliberately don't do with the people named in them, and your rights — is in [the privacy policy](/legal/privacy). For anything else data-protection related, is the address. ## What happens after you report We fix what we can and tell you what we've done. Corrections to enrichment usually apply to the whole class of postings that hit the same bug, not just your one row — which is why one good report is disproportionately useful. ## Next Sources, refresh cadence, and expiry. Zero results, missing fields, and other technical puzzles.