Skip to main content
An ask is anything you are waiting on Apostra for: help with something broken, a product capability, supply you want to buy, an integration, or a commercial question. Every ask has one type:

​
One tool to file or answer an ask

Agents on /mcp/v3 use save_ask for every type. A new ask sends kind: "create" and carries a short title; support adds detail, supply adds subject and channel (and, if you know them, countries), and integration adds subject. If the type is unclear, omit it rather than delaying the request — Apostra routes it. subject and channel belong only to the types that name a thing: send neither on a support, product, or commercial ask, and send channel and countries only on a supply ask. save_ask takes two shapes, and a call carries the keys of one of them: A call that mixes them is refused with the shape it matched and the keys that shape takes. Nothing is filed or changed. If Apostra has not yet set up your account for product-request tracking, a product ask is still recorded: it goes to Apostra Support instead. The response has type: "support", an escalationUid reference, and a warning that says why, and the ask appears as a support ask when you read it back. Accounts that are set up keep the product route. save_ask returns an opaque askId when the ask can be addressed later. Pass that id back with kind: "update" and requester.state (and an optional requester.note) to record your answer. This is the same requester object get returns for the ask:
  • confirmed_resolved — the requested outcome happened.
  • accepted — you acknowledge an answer that closed the ask without a change.
  • still_blocked — the release or answer did not unblock you.
  • withdrawn — you no longer want the ask pursued.
Your answer does not overwrite Apostra’s status. The two remain side by side, so “we marked it resolved” and “you are still blocked” can both be true.

​
Name the countries on a supply ask

A supply ask names one publisher domain in subject and one channel in channel. To say where you want to buy that publisher inventory, add countries: one to 50 ISO 3166-1 alpha-2 country codes.
  • Each code must be an assigned country code such as NL or DE. Lower case is accepted and stored in upper case, and a repeated code is kept once. A region label such as EMEA is not a country code and is refused, so name the countries.
  • countries is accepted only on a supply ask. On any other type the call is refused with VALIDATION_FAILED and the error names countries.
  • It records where you want to buy. Leaving it out means you named no country, not every country. It never narrows which sellers or products discovery returns.
  • One ask still names one domain and one channel. To ask for 25 domains, file 25 asks.
  • Filing the same ask again, for the same account, domain and channel, adds the new countries to those already recorded and never removes one. A filing without countries leaves them as they are.
  • To drop a country, withdraw the ask (requester.state withdrawn) and file it again with the countries you want. Filing a supply ask you withdrew reopens it, and its countries become exactly the ones in the new filing, or none if the filing names none. The response says “Reopened your supply ask”. Only your own withdrawal reopens an ask: an ask you answered confirmed_resolved stays as it is when you file it again, and its countries are added to as above.
  • The ask you read back carries countries: the recorded codes in alphabetical order, or an empty list when you named none. The same list is on the supplyRequest in the save_ask response, and market there is unchanged.

​
Read your asks

Use search({ kind: "ask" }) from either a buyer or seller account. You can narrow by type or open/closed state. Use the returned opaque id with get({ kind: "ask", id }) for one ask. A supply ask also returns its countries. The REST read remains available at GET /api/v2/asks. All reads are scoped to the authenticated account; another account’s id looks the same as a missing id.

​
When an ask is delivered

Closing an internal issue or merging a pull request does not close your ask. When work explicitly linked to your ask is verified as live in production, Apostra sends an update to your notifications feed and shows the same resolution in Your requests, the REST API, and MCP search and get. Ask-resolution updates are always-on. If one is unread when you begin a new Apostra conversation, Apostra includes it in the account update summary even when you have not opted into optional notification categories. The ask remains in your recent history for 90 days. It appears as Done when Apostra shipped a change, or Closed when Apostra recorded an explicit no-change outcome. The resolution includes:
  • the release version and date;
  • what changed, or why no change was made;
  • anything you should do next; and
  • whether the update was delivered.
Delivery completes Apostra’s track; it does not answer for you. Tell Apostra what happened, or pass the ask id and requester.state to save_ask. Use confirmed_resolved when the requested outcome happened, accepted to acknowledge a no-change answer, or still_blocked when you still need help. A disputed answer keeps the release history and your previous notes.

​
Confirmation and compatibility

Inside Apostra, a customer-authored filing is staged for confirmation before it creates team-visible work. A direct authenticated /mcp/v3 save_ask call is the execution action itself; it does not create a separate Apostra confirmation card. Both paths apply the same validation, redaction, authorization, routing, and account-scoping checks. list_my_requests remains as a deprecated alias through the API release that contains this change. It may be removed no earlier than the following API release, after usage review; new agents should use search and get now. The retired writers are report_issue, report_integration_need, track_my_product_ask, create_supply_request, and remove_supply_request. New Apostra turns no longer receive the first three tools. POST /api/v2/supply-requests and POST /api/v2/supply-requests/remove keep working through this API release and route through save_ask. They may be removed no earlier than the following API release, after usage review; builders should replace them now. Supply asks are scoped directly to the authenticated platform account; they do not require or create a Linear customer record.

Use asks in Apostra

See how asks appear in chat and in Your requests.