← Platform Path
API
Tokens

Run Platform Path from your own code

Both metered lanes are available over HTTP and each returns one JSON object. The division of labour: the page reads who the target role serves, resolves the track and archetype, audits the record against what the track is screened on, ranks the steps, plans the loop and checks the offer, then hands it all to the run as facts. The run writes the plan or the prep; the page then holds it to its own facts (ppreply.js).

Base URL and the response shape

Every endpoint lives under https://api.skillsafe.ai/v1/app-api, and every response has one shape:

{ "ok": true,  "data":  { ... } }
{ "ok": false, "error": { "code": "...", "message": "..." } }

The token is minted for this app (the guest call takes {"slug":"platform-path"}), so no slug header is needed afterwards. Send it as Authorization: Bearer YOUR_TOKEN. The run body is the input object, sent bare.

StatusCodeMeaning
400validation_errorThe body is not a JSON object, or a required key (task, candidate, evidence, facts) is missing. The page always sends all five of task, candidate, evidence, carry, facts; carry is an empty string for plan.
401unauthorizedNo token, or a stale one. Mint a guest token or sign in again.
402insufficient_creditsThe balance is under min_credits. Price with /estimate first.
403forbiddenA guest token tried to run: both lanes are metered and need a personal sign-in.
404not_foundUnknown job id.
429rate_limitedBack off and retry.
5xxserver_errorTransient. Retry with the same Idempotency-Key so a retry never double-bills.

The task field comes first

Two lanes, chosen by task, in the order the work runs - choose and break in, then pass the loop and weigh the offer:

A missing or unknown task is answered as plan; an internal-developer-platform target is refused before it runs. Both lanes send the same five fields. The facts are the page's checks, steps and loop, one row per line, and a line starting "must:" is a rule the reply has to hold. The page's handoff carries the plan into carry for the prep lane.

The input

FieldRequiredWhat
taskyesplan or prep. If it is missing or neither, do plan and set "task": "plan".
candidateyeswhere the person stands, the target track and archetype, the ecosystem, the deadline, one-off or compounding, portfolio hours, any offer and how it was benchmarked, and the plan date; "not given" means not given.
evidenceyesthe target posting and the track record, one item per line as kind | item | describable without confidential detail.
carrysend it (empty for plan)prep task only: the plan decisions when the plan task ran first, or a sentence saying no plan was carried over. Either way, never mention this input or any input by its name in your reply.
factsyesthe page's checks, one line each as area | id | status | evidence, the track, the archetype and what is missing, the steps as step | what | note, and the loop as round | name | judges | drill. A line starting "must:" applies to your reply.
retry_notenooptional; if present, your previous reply was unusable - follow it.

The rules the model applies

From the source skill, @samber/developer-platform-career - the only standard the run applies:

House rules

The replies

plan

Write the career plan.

  1. summary - one sentence, at most 40 words: the target, and the first thing to do.
  2. population - one sentence: whether the target role is the internal-platform or the external-API population, and what in the posting or the answers shows it.
  3. target - track (the page's id), archetype (the page's id), why (one sentence: what a hire there is measured on, for this person).
  4. steps - one object per step the facts list, in that order, no others: step (its id), action (one sentence: what to do, in this person's terms), done_when (one sentence: the observable result), hypothesis (true for the internal-API step, false otherwise).
  5. portfolio - one object per missing artefact kind the facts name (one to keep current when nothing is missing): kind (rfc, api, oss, partner or pm), artefact (one sentence: the specific thing to make, from this person's own work), proves (one sentence: what a screener reads in it).
  6. caveats - at most 4 short strings; [] when there is nothing to say.
{
  "task": "plan",
  "summary": "one sentence",
  "population": "one sentence",
  "target": { "track": "platform", "archetype": "apifirst", "why": "one sentence" },
  "steps": [ { "step": "portfolio", "action": "one sentence", "done_when": "one sentence", "hypothesis": false } ],
  "portfolio": [ { "kind": "api", "artefact": "one sentence", "proves": "one sentence" } ],
  "caveats": [ ]
}

The page holds it to its own facts (check() in ppreply.js; any warning makes the reply flagged): the reply answers the task it was sent; no web link; no backticks; no gendered pronoun; no input field named; no figure the input does not give; a summary of at most 40 words; a population sentence naming both the internal-platform and external-API populations; the page's track and archetype with what a hire is measured on; the page's steps in order, each with an action and a done-when, the internal-API step - and only it - labelled a hypothesis; one artefact per missing kind; no certification treated as a gate; no ladder presented as universal; PlatformCon never offered for this track.

prep

Write the interview preparation and the offer stance.

  1. summary - one sentence, at most 40 words.
  2. rounds - one object per round the facts list, in that order, no others: round (its id), judges (one sentence: what it decides, for this posting), drill (one sentence: the practice to do before it, from this person's own work).
  3. practice - at least three short strings: practice prompts drawn from the target posting.
  4. offer - anchor (one sentence: the general engineering or product-management ladder and the equivalent level), source (the named, dated source as the input gives it, or "needs live verification" and say so), verdict (one sentence: hold, negotiate or re-benchmark, and why; when there is no offer, how to benchmark one when it comes).
  5. caveats - at most 4 short strings; [] when there is nothing to say.
{
  "task": "prep",
  "summary": "one sentence",
  "rounds": [ { "round": "apidesign", "judges": "one sentence", "drill": "one sentence" } ],
  "practice": [ "a prompt" ],
  "offer": { "anchor": "one sentence", "source": "a named, dated source", "verdict": "one sentence" },
  "caveats": [ ]
}

The page requires: the reply answers the task it was sent; the same text rules; the page's rounds in order, each with what it judges and a drill, no coding drill for the PM track; at least three practice prompts; a take-home SDK or API design called plausible, not confirmed; the offer anchored to the general engineering or PM ladder at the equivalent level, never a platform-title salary search, with a dated source or flagged for live verification; when the offer was not benchmarked on the ladder, a verdict to re-benchmark it.

Worked examples

Three runs from the page's free samples (invented companies): the plan for a backend engineer who builds internal APIs today, the prep for the same person carrying that plan, and the plan for a PM interviewing now with an offer benchmarked the wrong way. Each input is exactly what the page sends; each reply is the saved reply the sample replays, shipped unedited - but the facts and long strings are shortened in this display only, and every cut is listed under the example. The last line is the page's own check of the full reply.

plan - Internal APIs to a public API platform

The page read it as: a platform move with gaps to close; track platform at apifirst; steps internal, portfolio, loop; 3 of 4 gates; failing checks: none.

Input (facts is 3024 characters; the first 1392 are shown):

{
 "task": "plan",
 "candidate": "Label: Backend engineer, internal APIs\nWhere they stand: Building internal APIs today; today: Backend engineer on an order-management team; I design the internal REST APIs three other teams call.; building internal APIs: yes\nTarget: Platform Engineer / Architect (read from the posting) at an infrastructure or API-first company (read from the posting); ecosystem to be credible in: rest\nDeadline: one to three months; a compounding move across employers; portfolio hours per week: 4\nOffer: none yet; plan date: 2026-11-02",
 "evidence": "Target posting:\nPlatform Engineer, API Platform - Zindrel Pay\nThe API is the product at Zindrel Pay. You will design and run the public API and SDKs that external developers use to take card payments.\nYou will own versioning, idempotency and error design across the API surface, and review design documents with the team.\n\nTrack record (kind | item | describable without confidential detail):\n- an RFC or design doc | Design doc - internal order-events API, describable without confidential detail | yes\n- an RFC or design doc | Design doc - retry policy for the fulfilment service, can describe it | yes",
 "carry": "",
 "facts": "The page's checks (0 fail, 1 warn, 3 pass, 5 n/a); verdict: a platform move with gaps to close:\n- The target | stage | na | Building internal APIs today; building internal APIs today\n- The target | population | pass | external consumers - the posting names public api, sdks, external developers\n- The target | target | pass | Platform Engineer / Architect (read from the posting) at an infrastructure or API-first company (read from the posting) - measured on API design quality, infra reliability, contract stability\n- The track record | portfolio | warn | has an RFC or design doc; missing an API or schema design shipped\n- The track record | certs | pass | no certification listed\n- The loop | loop | na | Recruiter call, Hiring-manager interview, API-design interview, System-design interview, Team interviews (two to five) (the executive round only for senior hires)\n- The loop | split | na | judged on developer-facing usability and misuse-resistance, apart from general system design\n- The offer | offer | na | no offer yet\n- The page's plan | steps | na | 1. internal, 2. portfolio, 3. loop\nTrack: platform; archetype: apifirst; what this track is screened on: api, rfc; missing: api.\nThe steps (step | what | note):\n- internal | Use internal API work as the practice ground | a hypothesis, not an established route: you already build internal APIs - write them up as practice for the\n\n[... 1632 more characters cut from this display ...]"
}

Reply:

{
 "task": "plan",
 "summary": "Target the Platform Engineer, API Platform role at Zindrel Pay; first, rewrite your order-events API design doc as a public-facing API design with versioning, idempotency and error choices spelled out.",
 "population": "This is the external-API population, not the internal-platform one: the Zindrel Pay posting says the API is the product and names a public API and SDKs used by external developers taking card payments.",
 "target": {
  "track": "platform",
  "archetype": "apifirst",
  "why": "At an API-first payments company you would be measured on API design quality, reliability and contract stability, which is exactly the versioning, idempotency and error design the posting asks you to own."
 },
 "steps": [
  {
   "step": "internal",
   "action": "Treat the internal REST APIs that three other teams call as your practice ground, writing up how you handled versioning, retries and errors for those consumers - a hypothesis, not an established route into the external track.",
   "done_when": "You have a short write-up of one internal API showing the consumer-facing decisions you made and what you would change for outside developers.",
   "hypothesis": true
  },
  {
   "step": "portfolio",
   "action": "Using your four weekly hours, turn the order-events API into a shipped API or schema design you can show: a published spec with resource shapes, idempotency keys and a documented error model.",
   "done_when": "A spec you can walk a screener through exists alongside your two design docs, with every example free of confidential detail.",
   "hypothesis": false
  },
  {
   "step": "loop",
   "action": "Prepare the recruiter, hiring-manager, API-design, system-design and team rounds, practising a card-payments API design separately from the service sketch behind it.",
   "done_when": "You can design a payments API with actionable errors in one session and then sketch the service behind it in a second, each judged on its own terms.",
   "hypothesis": false
  }
 ],
 "portfolio": [
  {
   "kind": "api",
   "artefact": "A public-style API spec for your order-events API, with versioning rules, idempotent create calls and an error catalogue drawn from your retry-policy work on the fulfilment service.",
   "proves": "That you can design an interface outside developers consume that is clear, predictable and hard to misuse, not just one that scales."
  }
 ],
 "caveats": [
  "Your record has design docs but no shipped API or schema design yet; the spec above is what closes that gap.",
  "Using internal APIs as practice is a hypothesis, not a proven route into external API work.",
  "With a one-to-three-month window and four hours a week, keep the spec to one API rather than several."
 ]
}

What step 5 prints for it: internal: You have a short write-up of one internal API showing the consumer-facing decisions you made and what you would change for outside developers. | portfolio: A spec you can walk a screener through exists alongside your two design docs, with every example free of confidential detail. | loop: You can design a payments API with actionable errors in one session and then sketch the service behind it in a second, each judged on its own terms.

The page's check: kept - nothing to flag

prep - Internal APIs to a public API platform

The input carries the saved plan (R.laneForm fills carry from the plan reply), as the page's handoff does. The page's loop: recruiter, manager, apidesign, system, team.

Input (facts is 2974 characters; the first 1392 are shown):

{
 "task": "prep",
 "candidate": "Label: Backend engineer, internal APIs\nWhere they stand: Building internal APIs today; today: Backend engineer on an order-management team; I design the internal REST APIs three other teams call.; building internal APIs: yes\nTarget: Platform Engineer / Architect (read from the posting) at an infrastructure or API-first company (read from the posting); ecosystem to be credible in: rest\nDeadline: one to three months; a compounding move across employers; portfolio hours per week: 4\nOffer: none yet; plan date: 2026-11-02",
 "evidence": "Target posting:\nPlatform Engineer, API Platform - Zindrel Pay\nThe API is the product at Zindrel Pay. You will design and run the public API and SDKs that external developers use to take card payments.\nYou will own versioning, idempotency and error design across the API surface, and review design documents with the team.\n\nTrack record (kind | item | describable without confidential detail):\n- an RFC or design doc | Design doc - internal order-events API, describable without confidential detail | yes\n- an RFC or design doc | Design doc - retry policy for the fulfilment service, can describe it | yes",
 "carry": "Population: This is the external-API population, not the internal-platform one: the Zindrel Pay posting says the API is the product and names a public API and SDKs used by external developers taking card payments.\nTarget: Platform Engineer / Architect at an infrastructure or API-first company - At an API-first payments company you would be measured on API design quality, reliability and contract stability, which is exactly the versioning, idempotency and error design the posting asks you to own.\nSteps: internal - Treat the internal REST APIs that three other teams call as your practice ground, writing up how you handled versioning, retries and errors for those consumers - a hypothesis, not an established route into the external track.; portfolio - Using your four weekly hours, turn the order-events API into a shipped API or schema design you can show: a published spec with resource shapes, idempotency keys and a documented error model.; loop - Prepare the recruiter, hiring-manager, API-design, system-design and team rounds, practising a card-payments API design separately from the service sketch behind it.\nPortfolio: api - A public-style API spec for your order-events API, with versioning rules, idempotent create calls and an error catalogue drawn from your retry-policy work on the fulfilment service.",
 "facts": "The page's checks (0 fail, 1 warn, 3 pass, 5 n/a); verdict: a platform move with gaps to close:\n- The target | stage | na | Building internal APIs today; building internal APIs today\n- The target | population | pass | external consumers - the posting names public api, sdks, external developers\n- The target | target | pass | Platform Engineer / Architect (read from the posting) at an infrastructure or API-first company (read from the posting) - measured on API design quality, infra reliability, contract stability\n- The track record | portfolio | warn | has an RFC or design doc; missing an API or schema design shipped\n- The track record | certs | pass | no certification listed\n- The loop | loop | na | Recruiter call, Hiring-manager interview, API-design interview, System-design interview, Team interviews (two to five) (the executive round only for senior hires)\n- The loop | split | na | judged on developer-facing usability and misuse-resistance, apart from general system design\n- The offer | offer | na | no offer yet\n- The page's plan | steps | na | 1. internal, 2. portfolio, 3. loop\nTrack: platform; archetype: apifirst; what this track is screened on: api, rfc; missing: api.\nThe steps (step | what | note):\n- internal | Use internal API work as the practice ground | a hypothesis, not an established route: you already build internal APIs - write them up as practice for the\n\n[... 1582 more characters cut from this display ...]"
}

Reply:

{
 "task": "prep",
 "summary": "Prepare the Zindrel Pay loop by turning your order-events design doc and fulfilment retry policy into a card-payments API story, and practise the API-design round apart from the system-design round.",
 "rounds": [
  {
   "round": "recruiter",
   "judges": "Whether your move from internal order-management APIs to a public payments API reads as motivated and at the right level for Zindrel Pay.",
   "drill": "Tell, in two minutes, how you design the internal REST APIs three other teams call and why you now want external developers taking card payments as your consumers."
  },
  {
   "round": "manager",
   "judges": "Whether your scope fits a team that owns versioning, idempotency and error design across a public API and its SDKs.",
   "drill": "Pick one decision in your order-events design doc you would reverse now that the consumers would be outside developers, and explain why."
  },
  {
   "round": "apidesign",
   "judges": "How clear, predictable and hard to misuse a card-payments interface you design is for developers integrating it, not how far it scales.",
   "drill": "Design a create-payment call with an idempotency key, a versioning rule and an error catalogue whose codes tell a developer what to fix, borrowing from your fulfilment retry policy."
  },
  {
   "round": "system",
   "judges": "Whether you can architect the distributed service behind the payments API you just designed.",
   "drill": "Sketch the service behind your create-payment call, showing where idempotency keys are stored and how retries from your fulfilment work would avoid double charges."
  },
  {
   "round": "team",
   "judges": "How you work with the team and judge an integration that is going wrong, including in design-document reviews.",
   "drill": "Review a failing integration in which a developer gets duplicate charges after a timeout, and say what you would ask first before touching the API."
  }
 ],
 "practice": [
  "Design the versioning policy for a public card-payments API so that an older SDK keeps working after a field is added.",
  "Walk through how an idempotency key on a payment request behaves when the client retries after a network timeout.",
  "Draft the error model for a declined card versus an invalid request, so a developer knows which one to retry.",
  "Review a design document that proposes renaming a response field across the API and the SDKs, and say what you would push back on."
 ],
 "offer": {
  "anchor": "Benchmark against the general software-engineering ladder at the level Zindrel Pay places you, not against a platform-specific title.",
  "source": "needs live verification - no offer or dated ladder source exists yet, so find a named, dated source for that level once an offer arrives.",
  "verdict": "No offer yet: when one comes, re-benchmark it against a named, dated general-engineering band at its stated level before deciding to hold or negotiate."
 },
 "caveats": [
  "Your record has design docs but no shipped API or schema design yet, so the order-events spec is the gap to close before the API-design round.",
  "A take-home designing an SDK or API surface is plausible here, not confirmed.",
  "Treating your internal APIs as practice for the external track is a hypothesis, not an established route."
 ]
}

What step 5 prints for it: recruiter: Tell, in two minutes, how you design the internal REST APIs three other teams call and why you now want external developers taking card payments as your consumers. | manager: Pick one decision in your order-events design doc you would reverse now that the consumers would be outside developers, and explain why. | apidesign: Design a create-payment call with an idempotency key, a versioning rule and an error catalogue whose codes tell a developer what to fix, borrowing from your fulfilment retry policy. | system: Sketch the service behind your create-payment call, showing where idempotency keys are stored and how retries from your fulfilment work would avoid double charges. | team: Review a failing integration in which a developer gets duplicate charges after a timeout, and say what you would ask first before touching the API.

The page's check: kept - nothing to flag

plan - A PM with talks and an offer in hand

The page read it as: a platform move with gaps to close; track apipm at bolton; steps loop, offer, internal, portfolio; 2 of 5 gates; failing checks: portfolio, certs, offer.

Input (facts is 3978 characters; the first 1398 are shown):

{
 "task": "plan",
 "candidate": "Label: Product manager, first API role\nWhere they stand: Not in platform work yet; today: Product manager on a scheduling product; I give talks about developer experience and write a product newsletter.; building internal APIs: no\nTarget: API Product Manager (your answer) at a company bolting a public API onto its product; ecosystem to be credible in: webhooks\nDeadline: interviewing now; a one-off move - the next role fast; portfolio hours per week: 2\nOffer: API Product Manager; Senior PM; $172k base; benchmarked by: a platform-title salary search; source: a crowdsourced search for API product manager salaries; plan date: 2026-11-02",
 "evidence": "Target posting:\nAPI Product Manager - Plimsodd\nPlimsodd is adding its first public API so partners can build on our scheduling product.\nYou will own the API roadmap, pricing for API access, and the developer portal external developers use.\n\nTrack record (kind | item | describable without confidential detail):\n- talks, posts or community work | Talk - developer experience at a regional product meetup | yes\n- talks, posts or community work | Blog - five posts on onboarding friction | yes\n- a certification | Certification - an API product certificate | yes\n- talks, posts or community work | Newsletter - monthly product newsletter | yes",
 "carry": "",
 "facts": "The page's checks (3 fail, 1 warn, 2 pass, 4 n/a); verdict: a platform move with gaps to close:\n- The target | stage | na | Not in platform work yet\n- The target | population | pass | external consumers - the posting names public api, developer portal, external developers\n- The target | target | pass | API Product Manager at a company bolting a public API onto its product - measured on general engineering delivery, with API design as one competency among several\n- The track record | portfolio | fail | has talks, posts or community work, a certification; missing API product, roadmap or pricing work and an RFC or design doc\n- The track record | certs | fail | Certification - the record leans on certification alone; no evidence shows employers weight it\n- The track record | devrel | warn | talks, posts and community work outnumber design artefacts - this track screens on API and system design judgment; advocate and educator roles are a different career\n- The loop | loop | na | Recruiter call, Hiring-manager interview, Scoping and design-thinking round, Technical conversation with an engineer, Written product exercise, Team interviews (two to five) (the executive round only for senior hires)\n- The loop | pmbar | na | scoping and communicating design thinking, not deep implementation; some loops add a technical conversation with an engineer, without code\n- The offer | offer | fail\n\n[... 2580 more characters cut from this display ...]"
}

Reply:

{
 "task": "plan",
 "summary": "Pursue the API Product Manager role at Plimsodd; start by drilling the scoping round, then re-benchmark your Senior PM offer against the general product-management ladder before any portfolio work.",
 "population": "This is the external-API population, not the internal-platform one: the Plimsodd posting names a first public API for partners, a developer portal and external developers building on the scheduling product.",
 "target": {
  "track": "apipm",
  "archetype": "bolton",
  "why": "At a company bolting its first public API onto a scheduling product, you would be measured on general delivery with API design as one competency, so your roadmap, pricing and portal judgment carry the screen."
 },
 "steps": [
  {
   "step": "loop",
   "action": "Since you are interviewing now, rehearse the recruiter, hiring-manager, scoping, technical-conversation, written-exercise and team rounds, starting with scoping a first public API for a scheduling product out loud.",
   "done_when": "You can scope a first public API in ten minutes, walk an engineer through one API call end to end without code, and hand over a one-page breaking-change memo.",
   "hypothesis": false
  },
  {
   "step": "offer",
   "action": "Re-benchmark the Senior PM offer at $172k base against the general product-management ladder at the Senior PM level, replacing the crowdsourced API product manager salary search with a named, dated source.",
   "done_when": "You hold a named, dated product-management ladder source for the Senior PM level and know whether $172k base sits inside that band.",
   "hypothesis": false
  },
  {
   "step": "internal",
   "action": "Take on an internal API at your current scheduling job as a lower-stakes first run at API product work - a hypothesis, not an established route.",
   "done_when": "You have owned the scope or roadmap of one internal API and can describe the decisions without confidential detail.",
   "hypothesis": true
  },
  {
   "step": "portfolio",
   "action": "With your two weekly hours, produce one artefact that combines API product thinking and a design doc, rather than another talk or post.",
   "done_when": "One describable document covering an API roadmap or pricing decision and its design reasoning is ready to share with a screener.",
   "hypothesis": false
  }
 ],
 "portfolio": [
  {
   "kind": "pm",
   "artefact": "A proposed roadmap and API-access pricing outline for a public scheduling API, building on your five posts about onboarding friction.",
   "proves": "That you can scope an API as a product, decide what partners get first and reason about how access is priced."
  },
  {
   "kind": "rfc",
   "artefact": "A short design doc for one scheduling endpoint and its webhook events, covering what partners receive, retries and how a breaking change would be handled.",
   "proves": "That you can structure and communicate API design thinking in writing, the judgment this track screens on."
  }
 ],
 "caveats": [
  "Your record has no API product, roadmap or pricing work and no design doc yet; the two artefacts above replace that gap.",
  "Your API product certificate is informational at best; no employer is shown to weight it, so lead with design work instead.",
  "Talks, posts and a newsletter point toward advocate or educator roles, which are a different career from this one.",
  "A platform-title salary search gives sparse crowdsourced data, so the $172k base is not yet benchmarked."
 ]
}

What step 5 prints for it: loop: You can scope a first public API in ten minutes, walk an engineer through one API call end to end without code, and hand over a one-page breaking-change memo. | offer: You hold a named, dated product-management ladder source for the Senior PM level and know whether $172k base sits inside that band. | internal: You have owned the scope or roadmap of one internal API and can describe the decisions without confidential detail. | portfolio: One describable document covering an API roadmap or pricing decision and its design reasoning is ready to share with a screener.

The page's check: kept - nothing to flag

Build the input yourself

Load the engine in node (global.window = global; require("./ppkit.js"); require("./ppreply.js")), then:

const K = PathKit, R = PathReply;
const f = K.form(Object.assign(K.blank(), { label: "Me", stage: "internal", archetype: "apifirst", track: "platform",
  posting: "Design the public API and SDKs external developers use.", record: "Design doc | internal events API, describable" }));
// f.popRead (who the role serves), f.trackUse, f.archUse, f.gaps, f.steps, f.loop, f.gates
// K.selfCheck(f), K.loopCsv(f) - the self-check and the loop prep sheet
const b = K.buildInput(f, "plan");                           // or "prep" (R.laneForm(form, "prep", plan) fills carry)
const wire = K.toWire(b.input);                              // POST this to /estimate and /run
// then: const reply = R.normalize(R.parseReply(job.output.output), "plan");
// R.check(reply, b)                                         // {status: kept or flagged, notes}

Get a token for the steps below from /tokens.html.

Step 1 — a tiny client helper

One function that sends JSON and unwraps the response. Paste a personal token from /tokens.html, or leave it empty and mint a guest token in step 2.

BASE="https://api.skillsafe.ai/v1/app-api"
TOKEN="YOUR_TOKEN"   # from https://platform-path.skillsafe.ai/tokens.html
api() { # api METHOD PATH [JSON-BODY]
  curl -s -X "$1" "$BASE$2" -H "Content-Type: application/json" \
    ${TOKEN:+-H "Authorization: Bearer $TOKEN"} ${3:+--data "$3"}
}

Step 2 — a token

A guest token is enough for /me and /estimate. A run is metered, so it needs a personal token: sign in on /tokens.html and copy it from there.

# a guest token (enough for /me and /estimate); a run needs your personal token from /tokens.html
TOKEN=$(curl -s -X POST "$BASE/guest" -H "Content-Type: application/json" -d '{"slug":"platform-path"}' | jq -r '.data.token')

Step 3 — GET /me

Who the token is (subject_type: user or guest) and the credit balance.

api GET /me | jq '.data | {subject_type, credits}'

Step 4 — POST /estimate

Free. The body is the run input itself, the bare object (never wrapped in {"input": ...}). hold_credits is a reservation, not the price; min_credits is what the balance must cover; model_alias reads gpt-terra.

# input.json: the run input object - {"task": "plan", "candidate": "Label: Backend engineer, internal APIs
Where they stand: ...", "evidence": "Target posting:
Platform Engineer, API Platform ...", "carry": "", "facts": "The page's checks (...); verdict: a platform move with gaps to close:
- The track record | portfolio | warn | ..."}
# - see the input table
api POST /estimate "$(cat input.json)" | jq '.data | {hold_credits, min_credits, model, model_alias, markup_bps, warnings}'

Step 5 — POST /run, then poll the job

Send an Idempotency-Key built from the lane and the input: a retry with the same key never bills twice. The page uses platform-path:<task>:<inputHash>:a<attempt> - the lane is part of the key, retry_note is left out of the hash - and its one automatic reformat retry is a new attempt number, named in the page as one extra run. A plan reply carries summary, population, target, steps, portfolio and caveats; a prep reply carries summary, rounds, practice, offer and caveats. The code below prints the gist of either: each step and when it is done, or each round and its drill.

KEY="platform-path:$(jq -r .task input.json):$(shasum -a 256 input.json | cut -c1-16):a1"
JOB=$(curl -s -X POST "$BASE/run" -H "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" \
  -H "Idempotency-Key: $KEY" --data @input.json | jq -r '.data.job_id')
while :; do
  J=$(api GET "/jobs/$JOB"); S=$(echo "$J" | jq -r '.data.status')
  case "$S" in succeeded|failed|cancelled) break;; esac; sleep 2
done
echo "$J" | jq -r '.data.output.output' > reply.json   # one JSON object, the reply contract
echo "$J" | jq '.data | {charged_credits, truncated}'
jq -r 'if .task == "prep" then (.rounds[] | "\(.round): \(.drill)") 
       else (.steps[] | "\(.step): \(.done_when)") end' reply.json

Step 6 — POST /run-stream

The same run as Server-Sent Events, with the same input.json. Browsers receive progress ticks rather than text deltas; the final done event carries the reply.

# Server-Sent Events: tick/delta events while the job runs, then a final event with the job
curl -N -s -X POST "$BASE/run-stream" -H "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" \
  -H "Idempotency-Key: platform-path:$(jq -r .task input.json):$(shasum -a 256 input.json | cut -c1-16):a1" --data @input.json