Skip to main content

Authentication & Environments

Environments

EnvironmentAPI base URLEnrollment host
Staginghttps://api.ext.stage.jetty.comhttps://www.stage.sayrhino.com
Productionhttps://api.ext.jetty.comhttps://www.sayrhino.com

Every partner starts on staging. Production access is granted by your Partner Success Manager after you complete testing.

Staging data is reset periodically and no real policies or charges are created there. You never need to construct enrollment host URLs by hand — Rhino returns fully-formed enrollment_url values pointing at the right host for the environment you called.

Everything below concerns the Partner API. If you ingest prospects by emitting partner webhook events, Rhino gives you an event destination and its credentials during onboarding, and you need none of the API sections here except the webhook signing secret. You may still want API credentials for reading prospect state on demand.

Authenticating API requests

The Partner API sits behind Rhino's API gateway. Requests are authenticated with an Auth0-issued JWT presented as a bearer token:

POST /partners/acme-properties/prospects HTTP/1.1
Host: api.ext.jetty.com
Authorization: Bearer <your JWT>
Content-Type: application/json

Content-Type: application/json is required on requests with a body.

Your Partner Success Manager provisions the Auth0 client credentials and the scopes attached to your token. Tokens are issued through the OAuth2 client credentials grant and are valid for 8,600 seconds — a little under two and a half hours. Cache one per process and refresh it as it nears expiry rather than requesting a fresh token for every call.

Requests that fail authentication receive a 401 with no body. An expired token is the most likely cause, so retry once with a fresh one. A 401 that persists with a token you know is valid is worth raising rather than retrying, since it can also originate in the gateway ahead of the API rather than in your credentials.

Property owner slugs

Every Partner API path is scoped to a property owner:

/partners/{owner_slug}/...

The slug identifies which of Rhino's clients a prospect belongs to. If you work with several property owners, you will have several slugs, and your credentials must be authorized for each. Rhino provides these during onboarding. An unrecognized slug returns 404.

Webhook signing secret

This secret signs the events Rhino sends you, and is unrelated both to API authentication and to the credentials you use to emit events to Rhino. Rhino holds one signing secret per property owner and shares it with you during onboarding — it is not retrievable through the API.

Use it to verify the X-Webhook-Signature header on every delivery you receive, as described in the Webhooks Overview. Store it as you would any other credential and request a rotation through your Partner Success Manager if it is ever exposed.

Domain allowlists

Two per-property-owner settings gate the embedded flow, and both are configured by Rhino rather than through the API:

  • Frame ancestors — the domains permitted to load the enrollment flow in an iframe
  • Event origin — the single origin Rhino posts postMessage events to

Send both to your Partner Success Manager before you begin integration testing. See Embedded SDA Flow for details.

API reference and OpenAPI specification

Rhino hosts a browsable reference for the Partner API, and neither it nor the underlying spec requires a token:

URL
Reference (ReDoc)https://api.stage.sayrhino.com/docs
OpenAPI spec (JSON)https://api.stage.sayrhino.com/openapi.json

Load openapi.json into your own tooling to generate a client. Note that these are served only from the sayrhino.com API host, not from the jetty.com host you send requests to — asking the latter for /docs returns a 404.

Next steps