Product rules

These aren't technical limitations — they're platform rules, applied the same way in the site, the API, and the MCP server.

The platform doesn't set prices

budget comes from the client, price from the carrier. /cost-estimate explains what a cost is made of, not what a trip should cost. There's no minimum, maximum, or recommended rate, in any response.

Phone numbers only show in the site, only after acceptance

No contact field — phone, email, a WhatsApp link — exists in the API, in any response, for any resource. Not even after an offer is accepted: offer.accepted (planned, as an event) won't contain a phone number. Numbers appear to both sides only in the site, when the client picks an offer.

Accepting an offer stays in the site

There's no POST /offers/{id}/accept in v1, and there won't be one through the API without a separate decision. An integrator can read offers, but the client picks from the site, signed in normally.

No bulk downloads

Public lists go page by page, through a cursor, with caps per key and per owner. There's no export endpoint or global data stream.

No data from Facebook groups

Free vehicles pulled from Facebook groups (no account, no name, no phone) don't appear in the API — not in the list, not individually. The filter is applied before pagination.

Invoices belong to Storno

There are no billing, VAT, or issuing resources in the Ajungem API. Billing integration stays each integrator's own concern, separately.

What this means for your integration

If your integration needs picking a carrier, phone numbers, or recommended prices, the answer is simple: you won't get them through the API. Send the person to the url link in the response — the site page does the rest.