Overview

The Pelcro Open API is the public, customer-facing API behind Pelcro's user interfaces. It powers the flows your end users go through on your site or app — registering, signing in, subscribing to plans, buying products, managing payment methods, and paying invoices — and is designed to be called from a web or mobile front end (through the Pelcro JS SDK or directly).

It adheres to the REST architectural style: predictable resource-based URLs, JSON (or form-encoded) request bodies, structured JSON responses, standard HTTP verbs, and conventional HTTP status codes.

📘

Open API vs Core API

The Open API (/api/v1/sdk) is for end-user, in-UI flows and authenticates as a customer. The Core API (/api/v1) is for server-to-server integrations and authenticates with an account API key. Use the Open API for anything a signed-in customer does in your storefront.

Use-cases

• Authentication: register customers, sign them in (password, social / IdP, or passwordless), and handle password resets.
• Subscriptions: subscribe a customer to a plan, change / cancel / reactivate / renew, and preview pricing & tax before committing.
• Memberships: invite and manage members on a membership subscription, and grant institutional access by IP range or email domain.
• E-commerce: list products, price an order, and check out.
• Billing: add and manage payment methods, and pay outstanding invoices.
• Profile & more: update the customer profile, manage addresses, and capture newsletter signups.

Identification

Every request must identify your account with your Site ID (site_id) — a publishable identifier (similar to a publishable key, not a secret), passed either as a query parameter or in the request body depending on the endpoint. See Identification for where to find it and how it's used.

Authentication

Open API endpoints are either public or protected:

• Public endpoints (e.g. site configuration, plans, newsletter signup, password reset) need only the site_id.
• Protected endpoints (e.g. the customer profile, subscriptions, payment methods, addresses) additionally require the customer's authentication token — a JWT returned by register / login — sent as a Bearer token:

Authorization: Bearer eyJ0eXA...   <-- the customer's auth_token

The token is returned as data.auth_token (and data.token) on the Customer resource. See Authentication for the full flow and header format.

Responses & errors

Successful responses return a structured JSON object (usually under a data key); the shape of each object is documented in Resources. Failures use conventional HTTP status codes with a small, predictable set of JSON error shapes — see Errors.