Synchronous requests

One entity, answered in the response, at twice the price.

Add /sync to any data operation and it answers with the record instead of with a batch id. It takes one target, creates the same batch under it, outranks every queued batch for a worker, drains it before replying, and hands you the result. It costs double.

The field is target, singular - not targets. A synchronous request is one entity in and one record out, and a targets array is refused with 400 invalid_request naming the batch path. That is deliberate: an endpoint capped at one that still took a list would be a batch endpoint with a limit on it, and the first thing anybody writes around one of those is a loop.

curl -X POST "https://api.easydata.win/v1/profiles/enrich/sync" \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"target": "https://linkedin.com/in/satyanadella"}'

{
  "data": {
    "batch_id": "afec9131-080b-4b96-b3bb-726249e4bbf8",
    "operation": "profiles.enrich",
    "status": "completed",
    "complete": true,
    "credits_used": 2,
    "result": {
      "item_index": 0,
      "input": "https://linkedin.com/in/satyanadella",
      "status": "succeeded",
      "credits_used": 2,
      "data": { "full_name": "Satya Nadella", "headline": "Chairman and CEO at Microsoft" }
    },
    "created_at": "2026-09-04T10:00:00Z",
    "completed_at": "2026-09-04T10:00:07Z"
  },
  "meta": { "requestId": "req_8f2ka91x" }
}

result is the same entry GET /batches/{batch_id}/results returns - the same fields, in the same shape. A target that failed is a result with status: "failed" and an error on it, never an absent one, and it costs nothing.

When to use it #

When something is waiting on the answer: a signup form resolving the profile URL somebody just pasted, a CRM field filling in while the rep is still looking at the record, a support tool that needs the company before it can route the ticket.

Not for volume, and the shape of the request says so: one entity per call. Anything you could enqueue and read later is cheaper, faster in aggregate and better at failure on the batch path - a thousand profiles submitted as one batch finish sooner than a thousand synchronous calls, and cost half as much.

Why double #

A batch is drained when the pool has room, and every customer benefits from that: workers are handed to whoever is next, paced per account, with nobody holding one open. A synchronous request is the opposite. It outranks every queued batch - while it is waiting, work on the batch path stands aside from any worker that could answer it - and then holds that worker for the length of your HTTP request. The price is what taking the pool out of that arrangement is worth.

It is a multiplier, never a second price list. Every number at /sync is the number on the batch path times two, including the ones that are arithmetic rather than a flat rate: a profiles/activity call whose reactions feed was refused costs 6 rather than 8, because it is still one credit per fetch that landed, doubled.

A failure still costs nothing. That promise is about what a credit is, not about which path you took.

What it will not do #

Four things are refused with 400 invalid_request rather than quietly downgraded. Each of them either turns a bounded request into an open-ended one or asks this path to be the batch path, and you would rather find out at submit time than through a timeout. find_emails is NOT one of them on /profiles/enrich/sync: one person is at most one lookup, which is bounded work of exactly the kind this path is for. It is refused on /sales/search/people/sync, where it would be one lookup per row.

• A targets array, of any length. This path takes target, one entity, and answers it with one result. The batch path is the one that takes a list, and it costs half as much.
• max_results above 100 on a search. That is one upstream page, which is one request to LinkedIn. The batch path goes to LinkedIn's own ceiling of 2,500.
• enrich, callback_url, webhook_tag and include_results. Per-row enrichment is a further fetch per row - a hundred of those is a batch however it was submitted. The other three name a delivery that happens later, and this request has already delivered.

When the deadline runs out #

You get 202 instead of 200, with complete: false, the same body shape and result: null. Nothing has been charged: the target is still being worked, at priority, under the same batch_id.

Read it from GET /batches/{batch_id}/results when it lands - the entry there is the one that would have been in result. Nothing is fetched twice and nothing is charged twice. There is no separate timeout shape to parse: complete is the one field to branch on, and a client that ignores the status code entirely is still correct.

Everything else is unchanged #

Same auth, same error envelope, same entry shape, same usage rollup. Idempotency-Key works: a retry finds the original batch and hands back its result rather than scraping and charging a second time. A synchronous batch also appears in GET /batches with priority: true on it, which is what explains the doubled credits when somebody reconciles the bill. The rate limits are NOT the same: a /sync call spends the ordinary request budget and then two ceilings of its own, both per organization - see rate limits.

The one exception is the concurrent-batch ceiling, which a synchronous request is exempt from. That ceiling is about work queued against the pool; this is not queued, and a customer running a bulk job should still be able to make the one lookup this path exists for.

Outgrowing this path is switching target for targets, dropping /sync and reading the entries from the cursor. Same auth, same records, same error vocabulary, and half the price.