Read China's remote-work briefs, budget included, as JSON

Applied here, and every response says so in a `note` field. The board accepts a keyword parameter and ignores it, so a nonsense term still returns the full front page. The engine therefore fetches board pages and matches your term against them, then reports exactly what it did: a search for '爬虫' across 6 pages scanned 120 briefs, matched 5, and set match_ratio_pct to 4.17. Raise `pages` to scan deeper, or narrow with category, city or type first so the pages you scan are already relevant.

It depends on contract shape, and getting this backwards will make full-time gigs look ten times cheaper than they are. On type full-time the budget is the per-workday rate multiplied by the quoted duration: one brief returned rate 1000 CNY per 8-hour day, duration 26 days, budget 26000 CNY. On type part-time the budget is the whole engagement: another returned budget 10000 CNY over 15 days with rate.per null and rate.amount simply repeating the budget. The `raw` string under both fields preserves the site's own wording, which is worth keeping for anything you display.

Because the site prints the applicant badge only when there is at least one, so on the 无人投递 shortlist there is nothing to parse and the field is null rather than 0. That shortlist shared just one of twenty ids with the default board in an earlier measurement, and returned null on all five rows checked, which is the filter proving itself from two directions. Read null as 'no applicants shown' on that sort, and as 'not published' elsewhere.

Because the site serves them from two different routes with no shared filter: the contract-shape board sits at /jobs/<type> and the city and role board at /job/<city>/<category>. Sending both is rejected with an INVALID_PARAM that spells this out, rather than one of them being quietly dropped and you receiving the wrong result set. If you need both, use `search` with a type and filter the returned rows yourself. city and category do combine with each other, since they share a route.

The poster's profile and the engagement's shape. On one brief, the board row gave employer.name null while `job` returned the poster's display name, their district-level location, team_size '10' and a funding_stage string, plus view_count 1105 against applicant_count 10, project_type ('数据挖掘/爬虫') and workdays_per_month. It also reads budget more precisely: the board row said 22000 CNY with period null, while `job` returned the same amount with period 'month' and the raw string identifying it as a monthly salary. meta.body_source confirms the description came out of the page's own structured data block.

No, and this is the unusual part of this board. The listing HTML ships the complete requirement, so a board row's description arrived at 1,244 characters covering responsibilities, required skills and the tech stack, with no fetch of the detail page. That is why `search` can match against fields 'description' and get a real result rather than a teaser: matching 数据采集 against descriptions found 6 briefs across 200 where matching titles alone found 3.

It bottoms out around page 164 on the unfiltered board, roughly 3,200 live briefs, and a filtered board ends much sooner. Past the end you get a NOT_FOUND that names the measured end rather than an empty success, so a paging loop terminates on a clear signal instead of silently collecting nothing. Consecutive pages carry no shared ids, checked at 0 overlap out of 20 between page 1 and page 2, so you can page without deduplicating.

Day-accurate at best, and the field names say so. The site publishes relative strings such as '2 天前发布' or '大约 1 个月前', which are preserved verbatim in published_relative, and published_approx_iso is that string resolved against the moment of your call, with published_approx_days_ago alongside it. A brief listed as two days old came back as an ISO timestamp exactly 48 hours before the query. Treat it as a bucket, not a publication timestamp, and never sort two same-day briefs by it.

Shixian API is a ReefAPI endpoint group for chinese remote-work briefs with the client's own budget, duration and requirements. It returns live JSON through POST requests under /shixian/v1.

Yes. ReefAPI starts with 1,000 free credits, no card required. Shixian calls use the same shared credit balance as every other ReefAPI engine.

No login to Shixian is needed for the API response. You call ReefAPI with your x-api-key header, and the playground can run live examples before you create a production key.

The page example is captured from a live search call, and production requests fetch live data through ReefAPI rather than a static sample.

Shixian actions currently cost 1-2 credits per successful call. Failed or blocked calls are free, and all APIs draw from one credit pool.

Yes. Connect ReefAPI once through MCP and your assistant can call shixian actions with the same key, credit pool and JSON envelope used by normal REST requests.