← Partner Onramp
API
Tokens

Run Partner Onramp from your own code

Both metered lanes are available over HTTP and each returns one JSON object. The division of labour: the page ranks the four onboarding rungs, audits the named journey for the skill's failure modes and reads the four funnel checkpoints against its thresholds, then hands it all to the run as facts. The run writes the onboarding design or the fixes; the page then holds it to its own facts (poreply.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":"partner-onramp"}), 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, program, journey, facts) is missing. The page always sends all five of task, program, journey, carry, facts; carry is an empty string for design.
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 - the journey partners walk, then where they stall today:

A missing or unknown task is answered as design. Both lanes send the same five fields. The facts are the page's checks, one row per line, and a line starting "must:" is a rule the reply has to hold. The page's handoff carries the design's decisions into carry for the fixes lane.

The input

FieldRequiredWhat
taskyesdesign or fixes. If it is missing or neither, do design and set "task": "design".
programyesthe platform, what partners build, the program today, time to a first app, data sensitivity, partners, the interview's yes/no answers, support capacity, deadline, mandate and effort; "not given" means not given.
journeyyesthe stages in order with their gate, owner and metric, the post-launch thresholds and whether each is disclosed, the funnel this quarter, and the page's issues in fix order.
carrysend it (empty for design)fixes task only: the design's decisions, when the design task ran first; may be empty.
factsyesthe page's checks, one line each as area | id | status | evidence, the verdict and the ranked rungs. 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/partner-app-onboarding - the only standard the run applies:

House rules

The replies

design

Write the onboarding design - the named journey, the four rungs, when commercial decisions land and what the funnel measures. A target or a threshold the input does not give is a proposal: start it with "Proposed: ".

  1. summary - one sentence, at most 40 words: the entry gate, when sandboxes arrive, and the first thing to change.
  2. stages - at least four objects in journey order: stage (a name; keep the program's stage names where they work), what (one sentence), gate (none, agreement, review, certification, pricing, payment or kyc), owner (the person the input names, else a role the input mentions, else "unassigned - needs an owner"), metric. Credentials are provisioned in a stage before any app review; certification never gates submission; pricing lands at launch.
  3. rungs - entry (self, split or reviewed), provisioning (dedicated, own or mirror), education (optional, credentialed or mandatory) - each exactly as the facts rank it - and support (the stacked ladder of forum, chat, office, managers, exactly as the facts stack it).
  4. promotions - objects: rung (a rung id), condition (one sentence: what would promote or delete it).
  5. commercial - monetization (the stage where the monetization model is asked), agreements (one sentence: when the seller agreement and revenue reporting land).
  6. funnel - checkpoints (four objects in order: checkpoint - signup-provisioned, provisioned-first-call, first-call-submitted, submitted-approved - and target, one short string), headline (one sentence naming time-to-first-submitted-app as self-defined).
  7. disclosure - one sentence: every post-launch threshold disclosed in the onboarding docs, naming the ones the input lists.
  8. caveats - at most 4 short strings; [] when there is nothing to say.
{
  "task": "design",
  "summary": "one sentence",
  "stages": [ { "stage": "Sign up", "what": "one sentence", "gate": "agreement", "owner": "a role", "metric": "a short string" } ],
  "rungs": { "entry": "self", "provisioning": "dedicated", "education": "optional", "support": [ "forum" ] },
  "promotions": [ { "rung": "chat", "condition": "one sentence" } ],
  "commercial": { "monetization": "Launch", "agreements": "one sentence" },
  "funnel": { "checkpoints": [ { "checkpoint": "signup-provisioned", "target": "a short string" } ], "headline": "one sentence" },
  "disclosure": "one sentence",
  "caveats": [ ]
}

The page holds it to its own facts (check() in poreply.js; any warning makes the reply flagged): the reply answers the task it was sent; no URL; no backticks; a summary of at most 40 words; the page's four rungs and its support ladder; at least four stages, each with a gate, an owner and a metric; credentials before any app review; no pricing gate in the first two stages; no certification gating submission; at least two promotion conditions; monetization at launch and when agreements land; the four checkpoints in order with targets; a self-defined headline metric; thresholds disclosed in the onboarding docs.

fixes

Write the fixes for the issues the page found, in its order - the biggest leak first.

  1. summary - one sentence, at most 40 words.
  2. fixes - one object per issue, in the facts' order: issue (friction, sandbox, validator, checklist, pricing, certification, walls, owners, instrument or enablement, exactly as the facts list it), fix (one or two sentences: the specific change - friction speeds up the first API call, sandbox moves credentials to signup, validator builds the pre-submission validator, checklist publishes the review checklist, pricing moves monetization to launch, certification becomes non-gating with quality enforced at review, walls are disclosed in the onboarding docs, owners names an owner and a metric per stage, instrument counts the four checkpoints, enablement fixes docs and enablement rather than the review team), owner (the person the input names, else a role the input mentions, else "unassigned - needs an owner"), metric (the number that shows it worked).
  3. caveats - at most 4 short strings; [] when there is nothing to say.
{
  "task": "fixes",
  "summary": "one sentence",
  "fixes": [ { "issue": "friction", "fix": "one or two sentences", "owner": "a role", "metric": "a short string" } ],
  "caveats": [ ]
}

The page requires: the reply answers the task it was sent; the same text rules; exactly the page's issues in its order; a fix, an owner and a metric each; and the specific change each issue needs - the first call, the sandbox at signup, the validator, the checklist, pricing at launch, non-gating certification, disclosure, owners, the four checkpoints, docs and enablement.

Worked examples

Three runs from the page's free samples (invented programs): the design for a CRM marketplace where partners stall, the fixes for the same program carrying that design, and the design for a banking-data API with a reviewed entry. 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.

design - A CRM marketplace where partners stall

The page read it as: partners stall before they ship; rungs split, dedicated, optional, forum+chat+managers; the biggest leak first-call-submitted; 1 of 5 gates; failing checks: decouple, commercial, disclosed, named, certification, friction, validator.

Input (journey is 2212 characters; the first 1393 are shown; facts is 3115 characters; the first 1388 are shown):

{
 "task": "design",
 "program": "Platform: FieldCRM\nWhat partners build and the program today: A field-sales CRM with a marketplace; ISVs and agencies build apps, and partners sign up but few ever submit.\nBuilds: Marketplace apps; existing: Signup exists, the journey after it is ad-hoc; time to a first working app: Days; data sensitivity: Medium; partners: A mix\nApps touch money, irreversible actions or other tenants' data: no; commercial sellers transact through us: yes; credibility is a buyer-facing signal: no; apps need production-realistic validation: no\nA pre-submission validator: no; the review checklist is published in onboarding: no; repeated questions cluster: yes; a recurring hard step needs a platform engineer: no; support capacity: One partner manager, two docs writers, a forum moderated weekly\nDeadline: no; a compounding ecosystem; effort ceiling: medium; as-of: 2026-11-01",
 "journey": "Journey stages in order (stage | what happens | gate | owner | metric):\n- Register | partner form, choose Free or Paid pricing for the future app | a pricing or monetization choice | Nadia Pellworth | signups\n- Application | partnerships team reviews the company | a human review | Nadia Pellworth | approval time\n- Build | dev sandbox and API credentials issued | no gate | NO OWNER | NO METRIC\n- Learn | FieldCRM Builder course | a certification | Tobin Arquell | completions\n- Submit | app submitted for marketplace review | a human review | Tobin Arquell | first-review pass rate\nPost-launch thresholds (threshold | disclosed in onboarding):\n- Marketplace review starts at 5 active installs | NO\n- Featured placement needs 6 months listed | NO\n- Partner tier at 50 installs | yes\nFunnel this quarter: signup to sandbox and credentials 45% (180 of 400); provisioned to first API call 50% (90 of 180); first API call to first app submitted 33.3% (30 of 90); submission to approval 40% (12 of 30); minutes to first call 25; first-review fail rate 45%; days to first submission 60; review days 6\nIssues in fix order: friction - 25 minutes to a first API call - over ten, the skill fixes onboarding friction before anything else (developer-tool funnels lose most partners before the first call); sandbox - credentials arrive at 'Build', after the review at 'Application' - partners approved to build cannot test;\n\n[... 819 more characters cut from this display ...]",
 "carry": "",
 "facts": "The page's checks (7 fail, 2 warn, 1 pass, 4 n/a); verdict: partners stall before they ship:\n- The four rung menus | entry | na | Agreement-split entry - commercial sellers transact through the platform - building stays ungated, a verified seller track gates selling\n- The four rung menus | provisioning | na | Instant dedicated dev tenancy - the default: a free dev tenancy at signup, no time limit, no payment info\n- The four rung menus | education | na | Optional parallel track - the default: courses and docs from day one, required by nothing\n- The four rung menus | support | na | Docs plus a community forum + Real-time community chat + Named partner managers (commercial partners only) - repeated questions cluster - real-time chat with periodic townhalls; commercial ISVs - named partner managers for that segment only\n- The journey | decouple | fail | credentials arrive at 'Build', after the review at 'Application' - partners approved to build cannot test\n- The journey | commercial | fail | pricing is asked at 'Register', before the app exists - it belongs at launch, the last gate before listing\n- The journey | disclosed | fail | Marketplace review starts at 5 active installs; Featured placement needs 6 months listed - not in the onboarding docs; partners meet it after they think they are done\n- The journey | named | fail | Build (no owner) (no metric)\n- The journey |\n\n[... 1727 more characters cut from this display ...]"
}

Reply:

{
 "task": "design",
 "summary": "Split entry keeps building ungated behind a form and program agreement, a dedicated dev tenancy and credentials arrive at signup, and the first change is cutting the 25 minutes to a first API call.",
 "stages": [
  {
   "stage": "Register",
   "what": "Partners fill in a form and accept the program agreement; nothing about money is asked and no human reviews them.",
   "gate": "agreement",
   "owner": "Nadia Pellworth",
   "metric": "signups"
  },
  {
   "stage": "Build",
   "what": "A free dedicated dev tenancy and API credentials are issued instantly at signup, with no time limit and no payment info.",
   "gate": "none",
   "owner": "Developer relations lead",
   "metric": "minutes to first API call"
  },
  {
   "stage": "Learn",
   "what": "The FieldCRM Builder course runs as an optional parallel track from day one and gates nothing.",
   "gate": "none",
   "owner": "Tobin Arquell",
   "metric": "completions"
  },
  {
   "stage": "Submit",
   "what": "The app is submitted for marketplace review against the review checklist published in the onboarding docs.",
   "gate": "review",
   "owner": "Tobin Arquell",
   "metric": "first-review pass rate"
  },
  {
   "stage": "Seller track",
   "what": "Partners who will sell complete the verified seller track, with agreement and KYC/KYB, before they transact.",
   "gate": "kyc",
   "owner": "Nadia Pellworth",
   "metric": "verified sellers"
  },
  {
   "stage": "Launch",
   "what": "The partner chooses Free or Paid pricing as the last gate before the listing goes live.",
   "gate": "pricing",
   "owner": "Nadia Pellworth",
   "metric": "apps listed"
  }
 ],
 "rungs": {
  "entry": "split",
  "provisioning": "dedicated",
  "education": "optional",
  "support": [
   "forum",
   "chat",
   "managers"
  ]
 },
 "promotions": [
  {
   "rung": "chat",
   "condition": "Real-time community chat stays because repeated questions cluster, and would drop back to the forum alone if they stop clustering."
  },
  {
   "rung": "managers",
   "condition": "Named partner managers serve commercial ISVs only and would never extend to every individual developer or agency."
  },
  {
   "rung": "education",
   "condition": "Mandatory certification would be considered only if first reviews still fail above roughly 30-40% after the pre-submission validator is in place and the failures trace to knowledge gaps."
  }
 ],
 "commercial": {
  "monetization": "Launch",
  "agreements": "The seller agreement lands at first listing through the verified seller track, and revenue reporting starts at the first sale."
 },
 "funnel": {
  "checkpoints": [
   {
    "checkpoint": "signup-provisioned",
    "target": "Proposed: near 100%, provisioned instantly at signup"
   },
   {
    "checkpoint": "provisioned-first-call",
    "target": "Proposed: first call under 10 minutes"
   },
   {
    "checkpoint": "first-call-submitted",
    "target": "Proposed: above 33.3% this quarter"
   },
   {
    "checkpoint": "submitted-approved",
    "target": "Proposed: first-review fail rate under 30%"
   }
  ],
  "headline": "Time-to-first-submitted-app, now 60 days against 6 days of review, is the headline metric and is self-defined by FieldCRM."
 },
 "disclosure": "The onboarding docs disclose every post-launch threshold up front: marketplace review starts at 5 active installs, featured placement needs 6 months listed, and partner tier comes at 50 installs.",
 "caveats": [
  "The Application review is removed so credentials no longer wait on it.",
  "A pre-submission validator comes before any mandatory education, given the 45% first-review fail rate.",
  "The Build owner is a proposed role; no person is named for it."
 ]
}

What step 5 prints for it: Register agreement | Build none | Learn none | Submit review | Seller track kyc | Launch pricing

The page's check: kept - nothing to flag

fixes - A CRM marketplace where partners stall

The input carries the saved design's decisions (R.laneForm fills carry from the design reply), as the page's handoff does. The issues in fix order: friction, sandbox, validator, checklist, pricing, certification, walls, owners, enablement.

Input (journey is 2212 characters; the first 1393 are shown; facts is 2909 characters; the first 1388 are shown):

{
 "task": "fixes",
 "program": "Platform: FieldCRM\nWhat partners build and the program today: A field-sales CRM with a marketplace; ISVs and agencies build apps, and partners sign up but few ever submit.\nBuilds: Marketplace apps; existing: Signup exists, the journey after it is ad-hoc; time to a first working app: Days; data sensitivity: Medium; partners: A mix\nApps touch money, irreversible actions or other tenants' data: no; commercial sellers transact through us: yes; credibility is a buyer-facing signal: no; apps need production-realistic validation: no\nA pre-submission validator: no; the review checklist is published in onboarding: no; repeated questions cluster: yes; a recurring hard step needs a platform engineer: no; support capacity: One partner manager, two docs writers, a forum moderated weekly\nDeadline: no; a compounding ecosystem; effort ceiling: medium; as-of: 2026-11-01",
 "journey": "Journey stages in order (stage | what happens | gate | owner | metric):\n- Register | partner form, choose Free or Paid pricing for the future app | a pricing or monetization choice | Nadia Pellworth | signups\n- Application | partnerships team reviews the company | a human review | Nadia Pellworth | approval time\n- Build | dev sandbox and API credentials issued | no gate | NO OWNER | NO METRIC\n- Learn | FieldCRM Builder course | a certification | Tobin Arquell | completions\n- Submit | app submitted for marketplace review | a human review | Tobin Arquell | first-review pass rate\nPost-launch thresholds (threshold | disclosed in onboarding):\n- Marketplace review starts at 5 active installs | NO\n- Featured placement needs 6 months listed | NO\n- Partner tier at 50 installs | yes\nFunnel this quarter: signup to sandbox and credentials 45% (180 of 400); provisioned to first API call 50% (90 of 180); first API call to first app submitted 33.3% (30 of 90); submission to approval 40% (12 of 30); minutes to first call 25; first-review fail rate 45%; days to first submission 60; review days 6\nIssues in fix order: friction - 25 minutes to a first API call - over ten, the skill fixes onboarding friction before anything else (developer-tool funnels lose most partners before the first call); sandbox - credentials arrive at 'Build', after the review at 'Application' - partners approved to build cannot test;\n\n[... 819 more characters cut from this display ...]",
 "carry": "Rungs: entry split, provisioning dedicated, education optional, support forum + chat + managers\nStages: Register (agreement, Nadia Pellworth); Build (none, Developer relations lead); Learn (none, Tobin Arquell); Submit (review, Tobin Arquell); Seller track (kyc, Nadia Pellworth); Launch (pricing, Nadia Pellworth)\nMonetization: Launch\nCheckpoints: signup-provisioned Proposed: near 100%, provisioned instantly at signup; provisioned-first-call Proposed: first call under 10 minutes; first-call-submitted Proposed: above 33.3% this quarter; submitted-approved Proposed: first-review fail rate under 30%",
 "facts": "The page's checks (7 fail, 2 warn, 1 pass, 4 n/a); verdict: partners stall before they ship:\n- The four rung menus | entry | na | Agreement-split entry - commercial sellers transact through the platform - building stays ungated, a verified seller track gates selling\n- The four rung menus | provisioning | na | Instant dedicated dev tenancy - the default: a free dev tenancy at signup, no time limit, no payment info\n- The four rung menus | education | na | Optional parallel track - the default: courses and docs from day one, required by nothing\n- The four rung menus | support | na | Docs plus a community forum + Real-time community chat + Named partner managers (commercial partners only) - repeated questions cluster - real-time chat with periodic townhalls; commercial ISVs - named partner managers for that segment only\n- The journey | decouple | fail | credentials arrive at 'Build', after the review at 'Application' - partners approved to build cannot test\n- The journey | commercial | fail | pricing is asked at 'Register', before the app exists - it belongs at launch, the last gate before listing\n- The journey | disclosed | fail | Marketplace review starts at 5 active installs; Featured placement needs 6 months listed - not in the onboarding docs; partners meet it after they think they are done\n- The journey | named | fail | Build (no owner) (no metric)\n- The journey |\n\n[... 1521 more characters cut from this display ...]"
}

Reply:

{
 "task": "fixes",
 "summary": "Cut the 25-minute first call first, then issue sandbox credentials at signup, add a validator for the 45% first-review fail rate, publish the checklist, move pricing to Launch and disclose the install and tenure walls.",
 "fixes": [
  {
   "issue": "friction",
   "fix": "Strip every step between signup and a first API call - prefilled credentials, a copy-paste quickstart against the dev sandbox - so the call that takes 25 minutes today lands in under ten.",
   "owner": "Developer relations lead",
   "metric": "Minutes to first call from 25 to under 10 (Proposed: under 10); provisioned to first API call above 50%"
  },
  {
   "issue": "sandbox",
   "fix": "Issue the dev sandbox and API credentials at Register instead of at Build after the Application review, and keep the partnerships review only on the seller track that gates selling.",
   "owner": "Nadia Pellworth",
   "metric": "Signup to sandbox and credentials from 45% (180 of 400) to Proposed: near 100%, provisioned instantly at signup"
  },
  {
   "issue": "validator",
   "fix": "Build a pre-submission validator that runs the marketplace review's automatable checks before Submit, since 45% of first reviews fail and none exists today.",
   "owner": "Tobin Arquell",
   "metric": "First-review fail rate from 45% to Proposed: under 30%"
  },
  {
   "issue": "checklist",
   "fix": "Publish the marketplace review checklist inside the onboarding docs so partners meet the requirements before Submit, not at their first rejection.",
   "owner": "Tobin Arquell",
   "metric": "Submission to approval above 40% (12 of 30) (Proposed: rising each quarter)"
  },
  {
   "issue": "pricing",
   "fix": "Remove the Free or Paid choice from Register and ask for the monetization model at Launch, the last gate before listing.",
   "owner": "Nadia Pellworth",
   "metric": "Zero pricing questions before Launch; Proposed: signup completion tracked before and after"
  },
  {
   "issue": "certification",
   "fix": "Make the FieldCRM Builder course at Learn an optional parallel track that no longer gates submission, and enforce quality at the marketplace review with the validator.",
   "owner": "Tobin Arquell",
   "metric": "Share of submissions blocked by certification at 0%; first API call to first app submitted above 33.3% (Proposed)"
  },
  {
   "issue": "walls",
   "fix": "Disclose in the onboarding docs that marketplace review starts at 5 active installs and that featured placement needs 6 months listed, alongside the already-disclosed 50-install partner tier.",
   "owner": "Nadia Pellworth",
   "metric": "Post-launch thresholds disclosed in onboarding: 3 of 3, up from 1 of 3"
  },
  {
   "issue": "owners",
   "fix": "Give Build an owner and a metric: the developer relations lead owns it and measures time from provisioning to first API call.",
   "owner": "Developer relations lead",
   "metric": "Stages with an owner and a metric: 5 of 5, up from 4 of 5"
  },
  {
   "issue": "enablement",
   "fix": "Put the effort into docs, samples and the forum for the stretch from first call to submission rather than the review team, since 60 days to a first submission dwarfs 6 days of review.",
   "owner": "Two docs writers",
   "metric": "Days to first submission from 60 to Proposed: under 30"
  }
 ],
 "caveats": [
  "Time-to-first-submitted-app is a self-defined headline metric.",
  "Targets marked Proposed are not given by the program.",
  "The one partner manager is for commercial ISVs only, not every developer."
 ]
}

What step 5 prints for it: friction Developer relations lead | sandbox Nadia Pellworth | validator Tobin Arquell | checklist Tobin Arquell | pricing Nadia Pellworth | certification Tobin Arquell | walls Nadia Pellworth | owners Developer relations lead | enablement Two docs writers

The page's check: kept - nothing to flag

design - A banking-data API with a reviewed entry

The page read it as: partners stall before they ship; rungs reviewed, mirror, credentialed, forum+chat+office+managers; the biggest leak submitted-approved; 4 of 5 gates; failing checks: instrumented.

Input (facts is 2516 characters; the first 1397 are shown):

{
 "task": "design",
 "program": "Platform: Corvalith\nWhat partners build and the program today: An open-banking data API; fintech ISVs build account-aggregation apps against customer financial data.\nBuilds: Both; existing: A full journey live, being revisited; time to a first working app: Weeks to months; data sensitivity: High; partners: Mostly commercial ISVs\nApps touch money, irreversible actions or other tenants' data: yes; commercial sellers transact through us: yes; credibility is a buyer-facing signal: yes; apps need production-realistic validation: yes\nA pre-submission validator: yes; the review checklist is published in onboarding: yes; repeated questions cluster: yes; a recurring hard step needs a platform engineer: yes; support capacity: Three partner engineers, a solutions architect per top-tier ISV\nDeadline: no; a compounding ecosystem; effort ceiling: high; as-of: 2026-11-01",
 "journey": "Journey stages in order (stage | what happens | gate | owner | metric):\n- Apply | company application and KYB | a human review | Lena Vashcombe | days to admission\n- Plan | solution design session with a partner engineer | no gate | Lena Vashcombe | sessions booked\n- Build | production-mirror sandbox and test credentials | no gate | Omar Quisset | first sandbox call\n- Certify | security self-assessment and Corvalith certificate | no gate | Omar Quisset | certificates\n- Launch | app submitted for security review, then pricing set | a human review | Lena Vashcombe | first-review pass rate\nPost-launch thresholds (threshold | disclosed in onboarding):\n- Production keys after a passed security review | yes\nFunnel this quarter: signup to sandbox and credentials not counted; provisioned to first API call not counted; first API call to first app submitted not counted; submission to approval 66.7% (6 of 9); minutes to first call not given; first-review fail rate 22%; days to first submission 70; review days 21\nIssues in fix order: instrument - the four checkpoints are not all counted - instrument them before the next stall; enablement - 70 days to a first submission against 21 days of review - the bottleneck is docs and enablement, not the review team",
 "carry": "",
 "facts": "The page's checks (1 fail, 1 warn, 4 pass, 4 n/a); verdict: partners stall before they ship:\n- The four rung menus | entry | na | Application-reviewed registration - weeks to a first working app - unguided partners fail, so a reviewed entry earns its overhead; the seller track (agreement, KYC/KYB) still gates selling at first listing\n- The four rung menus | provisioning | na | Production-mirror sandboxes - apps touch money, irreversible actions or other tenants' data - own-account-as-sandbox is deleted, not demoted; apps cannot be validated without production-realistic behavior - production-mirror sandboxes, rationed\n- The four rung menus | education | na | Credentialed education loop - partner credibility is a buyer-facing signal - named, displayable certificates, still non-gating\n- The four rung menus | support | na | Docs plus a community forum + Real-time community chat + Office hours + Named partner managers (commercial partners only) - repeated questions cluster - real-time chat with periodic townhalls; a recurring hard step needs a platform engineer, not a peer - office hours; commercial ISVs - named partner managers for that segment only\n- The journey | decouple | pass | a reviewed entry by design - access follows admission\n- The journey | commercial | pass | no pricing asked before launch\n- The journey | disclosed | pass | every threshold is in the onboarding docs\n-\n\n[... 1119 more characters cut from this display ...]"
}

Reply:

{
 "task": "design",
 "summary": "Entry stays application-reviewed with KYB, rationed production-mirror sandboxes and test credentials arrive right after admission, and the first change is counting all four funnel checkpoints.",
 "stages": [
  {
   "stage": "Admission",
   "what": "Each company and its KYB are reviewed before admission, because a first working build takes weeks to months and the data is highly sensitive.",
   "gate": "review",
   "owner": "Lena Vashcombe",
   "metric": "days to admission"
  },
  {
   "stage": "Build",
   "what": "A rationed production-mirror sandbox and test credentials are issued at admission, before any app review.",
   "gate": "none",
   "owner": "Omar Quisset",
   "metric": "first sandbox call"
  },
  {
   "stage": "Plan",
   "what": "A solution design session with a partner engineer helps partners through the recurring hard step.",
   "gate": "none",
   "owner": "Lena Vashcombe",
   "metric": "sessions booked"
  },
  {
   "stage": "Certify",
   "what": "The security self-assessment and Corvalith certificate run as a credentialed, displayable track that never gates submission.",
   "gate": "none",
   "owner": "Omar Quisset",
   "metric": "certificates"
  },
  {
   "stage": "Submit",
   "what": "The app is submitted for security review against the published checklist and the pre-submission validator.",
   "gate": "review",
   "owner": "Lena Vashcombe",
   "metric": "first-review pass rate"
  },
  {
   "stage": "Launch",
   "what": "Pricing is set as the last gate before listing, after the security review passes.",
   "gate": "pricing",
   "owner": "Lena Vashcombe",
   "metric": "apps listed"
  }
 ],
 "rungs": {
  "entry": "reviewed",
  "provisioning": "mirror",
  "education": "credentialed",
  "support": [
   "forum",
   "chat",
   "office",
   "managers"
  ]
 },
 "promotions": [
  {
   "rung": "own",
   "condition": "The partner's own account as sandbox stays deleted, not demoted, because apps touch money, irreversible actions or other tenants' data."
  },
  {
   "rung": "reviewed",
   "condition": "Reviewed entry would step down to agreement-split entry if a first working app came to take days rather than weeks and the data were less sensitive."
  },
  {
   "rung": "office",
   "condition": "Office hours stay while a recurring hard step still needs a platform engineer rather than a peer."
  },
  {
   "rung": "managers",
   "condition": "Named partner managers stay limited to commercial ISVs and never extend to every individual developer."
  }
 ],
 "commercial": {
  "monetization": "Launch",
  "agreements": "The seller agreement lands at first listing and revenue reporting starts at the first sale."
 },
 "funnel": {
  "checkpoints": [
   {
    "checkpoint": "signup-provisioned",
    "target": "Proposed: count admissions provisioned within a day"
   },
   {
    "checkpoint": "provisioned-first-call",
    "target": "Proposed: first sandbox call under 10 minutes"
   },
   {
    "checkpoint": "first-call-submitted",
    "target": "Proposed: count it this quarter, then set a target"
   },
   {
    "checkpoint": "submitted-approved",
    "target": "Proposed: hold at or above 66.7%"
   }
  ],
  "headline": "Time-to-first-submitted-app, now 70 days against 21 days of review, is the headline metric and is self-defined by Corvalith."
 },
 "disclosure": "Every post-launch threshold stays disclosed in the onboarding docs, including production keys only after a passed security review.",
 "caveats": [
  "The Apply stage is renamed Admission so the entry review reads apart from the security review.",
  "Only submission to approval is counted today; the other three checkpoints need instrumenting first.",
  "70 days to a first submission against 21 days of review points to docs and enablement, not the review team."
 ]
}

What step 5 prints for it: Admission review | Build none | Plan none | Certify none | Submit review | Launch pricing

The page's check: kept - nothing to flag

Build the input yourself

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

const K = OnrampKit, R = OnrampReply;
const f = K.form(Object.assign(K.blank(), { name: "Acme", sellers: "yes", mincall: "25",
  stages: "Apply | partner form | review | Ann | approvals\nBuild | sandbox and credentials | none | Bo | first calls\nSubmit | app submitted | review | Ann | pass rate" }));
// f.entry, f.provision, f.education (the ranked rungs), f.support.ladder, f.stageRows, f.funnel, f.issues (in fix order), f.gate
// K.journeyMd(f), K.funnelCsv(f) - the journey table and the funnel
const b = K.buildInput(f, "design");                         // or "fixes" (R.laneForm(form, "fixes", design) fills carry)
const wire = K.toWire(b.input);                              // POST this to /estimate and /run
// then: const reply = R.normalize(R.parseReply(job.output.output), "design");
// 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://partner-onramp.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":"partner-onramp"}' | 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": "design", "program": "Platform: FieldCRM
What partners build and the program today: ...", "journey": "Journey stages in order (stage | what happens | gate | owner | metric):
- Register | ... | a pricing or monetization choice | Nadia Pellworth | signups ...", "carry": "", "facts": "The page's checks (...); verdict: partners stall before they ship:
- The four rung menus | entry | na | ..."}
# - 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 partner-onramp:<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 design reply carries summary, stages, rungs, promotions, commercial, funnel, disclosure and caveats; a fixes reply carries summary, fixes and caveats. The code below prints the gist of either: each stage and its gate, or each issue and its owner.

KEY="partner-onramp:$(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 == "fixes" then (.fixes[] | "\(.issue): \(.owner)") 
       else (.stages[] | "\(.stage): \(.gate)") 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: partner-onramp:$(jq -r .task input.json):$(shasum -a 256 input.json | cut -c1-16):a1" --data @input.json