v2.3.0
Summary
Launch Pad 2.3.0 introduces the Partner API: a launch handshake that signs a partner's user into Launch Pad without a second sign-in, plus provisioning endpoints for creating those users and companies from the partner's own ids. The release also improves boundary processing reliability and documentation consistency.
New Features
1. Partner Launch (Single Sign-On Handshake)
A partner system can open Launch Pad for its users with no separate sign-in. The partner backend requests a short-lived, single-use launch code for one of its users, redirects the user's browser to the returned launch URL, and the Launch Pad launch page exchanges the code for a session. The launch call requires an API key enabled for partner provisioning; the exchange call needs no API key because the single-use code is the credential and travels in the request body so it never lands in access logs.
| Method | Endpoint | Description |
|---|---|---|
| POST | /api/partner/launch |
Issue a one-time launch code for a partner user, identified by the partner's external user id |
| POST | /api/partner/launch/exchange |
Exchange a one-time launch code for a Launch Pad session (JWT and refresh token) |
| Property | Condition | Description |
|---|---|---|
code |
POST /api/partner/launch | The single-use launch code |
launchUrl |
POST /api/partner/launch | The Launch Pad URL to redirect the user's browser to |
expiresInSec, expiresAtUtc |
POST /api/partner/launch | Lifetime of the code |
token |
POST /api/partner/launch/exchange | The Launch Pad session issued for the user |
2. Partner Provisioning
Provision Launch Pad users and companies from a partner system using the partner's own ids. All three endpoints are idempotent: calling them again with the same external ids returns the existing records instead of creating duplicates. Validation failures return a structured error code (for example UserNotFound, NotAuthorized) that partner systems can branch on. Restricted to API keys enabled for partner provisioning. Typical order: provision the company, provision the user, grant the user access to the company, then launch.
| Method | Endpoint | Description |
|---|---|---|
| POST | /api/partner/users |
Create the Launch Pad user for a partner's external user id, or return the existing one |
| POST | /api/partner/companies |
Create the Launch Pad company for a partner's external company id, or return the existing one |
| POST | /api/partner/company-accesses |
Grant a partner user access to a partner company, both identified by their external ids |
Properties
| Property | Type | Description |
|---|---|---|
partnerUserId |
string | The partner's own id for the user; Launch Pad keeps the mapping |
partnerCompanyId |
string | The partner's own id for the company; Launch Pad keeps the mapping |
| Property | Condition | Description |
|---|---|---|
newUserCreated, newCompanyCreated |
Provisioning calls | Whether the record was created by this call or already existed |
Improvements
- Boundary cleanup now reliably preserves interior boundaries (in-field obstacles) on geometries submitted through the Direct API, including shapes that slightly cross the outer boundary.
- API reference documentation is more consistent across endpoints, with standardized response type annotations.
New Schemas
| Schema | Description |
|---|---|
PartnerLaunchResponseModel |
One-time launch code, launch URL, and expiry |
PartnerLaunchExchangeResponseModel |
The Launch Pad session issued for a launch code |
PartnerUserResponse |
Resolved Launch Pad user id for a partner user, with a created flag |
PartnerCompanyResponse |
Resolved Launch Pad company id for a partner company, with a created flag |
PartnerCompanyAccessResponse |
Result of granting a partner user access to a partner company |
Questions?
For questions about these API changes, please contact [email protected] or refer to the API documentation.