canonical: https://jentic.com/apis/happyreturns.com/happyreturns

# Happy Returns Partner API

Happy Returns is the PayPal-owned reverse logistics service for retail brands, providing in-person Return Bar drop-offs and box-free returns. The Partner API exposes 16 endpoints to create, list, approve, reject, and refund returns, generate return shipping labels, look up Return Bar drop-off locations, and register webhooks for return-state events. It also surfaces eligible items for an order and aggregate return analytics. Authentication is a bearer API key in the Authorization header.

## For AI agents

Initiate retail returns, generate labels, find Return Bar drop-off locations, and process refunds via the Happy Returns Partner API.

## Scope

Does not handle outbound shipping, payment capture, or product catalog management - use for retail return initiation, labels, drop-offs, and refund instruction only.

## Capabilities

- Initiate a retail return for a customer order
- Approve or reject a pending return based on policy
- Generate a printable return shipping label or box-free QR code
- Look up Happy Returns Return Bar drop-off locations
- Process a refund against an approved return
- Register and manage webhooks for return-state events
- Pull aggregate return analytics for a brand

## Use cases

### Self-Service Return Portal

Power a brand-hosted return portal that lets shoppers start a return, pick a drop-off Return Bar, and download a QR code. The Partner API handles return creation via POST /returns, label or QR creation via POST `/returns/{returnId}/labels`, and Return Bar lookup via GET /return-bars. Box-free QR drop-offs typically refund within a day of scan.

Example prompt: Create a return for orderId 'ord-5821' via POST /returns, then generate a QR-code label via POST `/returns/{returnId}/labels` and surface the nearest Return Bar from GET /return-bars.

### Automated Return Approval and Refund

Approve eligible returns and trigger refunds automatically based on a brand's policy. Use POST `/returns/{returnId}/approve` when items are within the return window and POST `/returns/{returnId}/refund` to issue payment back. Combined with webhooks at /webhooks, this removes manual review for the majority of straightforward returns.

Example prompt: On webhook 'return.received' for returnId 'ret-3321', call POST `/returns/ret-3321/approve` and POST `/returns/ret-3321/refund` with the original order amount.

### Return Eligibility Check at Checkout

Surface return-eligible items at the customer's order page by calling GET `/orders/{orderId}/eligible-items` before they start a return. The endpoint returns line items still within the return window and not previously returned. This avoids customer frustration when an item is past the window or already refunded.

Example prompt: When a shopper opens the returns flow, call GET `/orders/ord-5821/eligible-items` and display only the items returned by the API.

### AI Agent Customer Service Returns

Wire an AI customer service agent that can handle 'I want to return order #5821' end-to-end through Jentic. The agent calls `/orders/{orderId}/eligible-items`, /returns, and `/returns/{returnId}/labels` in sequence, with the bearer API key stored centrally and never passed through agent prompts. Refund issuance can be gated behind human approval.

Example prompt: When a shopper asks 'I need to return my last order', look up eligible items, create a return, generate the label, and DM the QR code with the nearest Return Bar.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/returns` | Create a return |
| GET | `/returns/{returnId}` | Get return details |
| POST | `/returns/{returnId}/approve` | Approve a return |
| POST | `/returns/{returnId}/refund` | Process a refund |
| POST | `/returns/{returnId}/labels` | Generate a return label or QR |
| GET | `/return-bars` | List Return Bar drop-off locations |
| GET | `/orders/{orderId}/eligible-items` | Get items eligible for return |
| POST | `/webhooks` | Register a webhook |

## Key resources

- **Returns** — Create, list, fetch, update, approve, reject, and refund returns
- **Labels** — Return shipping labels and box-free QR codes
- **Return Bars** — Drop-off location lookup
- **Orders** — Return-eligible item lookup per order
- **Webhooks** — Return-state event subscriptions
- **Analytics** — Aggregate return analytics

## Why Jentic

- **Setup:** Wiring the Happy Returns Partner API by hand means setting its Authorization Bearer key on every call and building each return, label, and refund request yourself. Through Jentic you install once, import the Happy Returns Partner API from the API Directory, store the key once, and your agent calls it.
- **Permission scoping:** Happy Returns puts the return id in the URL path (`/returns/{returnId}/refund`), so a rule can pin your agent to one return: it can read and label that return and nothing else. You choose the operations it may call, so state-changing ones like approving a return or issuing a refund are not included unless you add them.
- **Credential handling:** Your Happy Returns Partner API key is stored once, encrypted, by your own Jentic One instance and injected as the Authorization Bearer header at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create a return' or 'get eligible items for an order', and Jentic returns the matching Happy Returns operation with its input schema so the agent calls the right endpoint without crawling the developer portal.

## Related APIs

- **Shopify Admin** — Source orders and inventory updates that feed Happy Returns flows.
- **Stripe** — Handle the underlying card refund when Happy Returns issues the refund instruction.
- **PayPal** — PayPal's broader merchant APIs (Happy Returns is owned by PayPal) for refunds and dispute handling outside the Return Bar network.

## FAQ

### What authentication does the Happy Returns Partner API use?

Happy Returns uses an API key passed as a Bearer token in the Authorization header. Through Jentic the key is stored encrypted in the vault and injected on each call, so it never enters the agent's prompt or tool transcript.

### Can I generate a return shipping label with the Happy Returns API?

Yes. POST `/returns/{returnId}/labels` generates a printable label or box-free QR code for an existing return. GET `/returns/{returnId}/labels` retrieves previously generated labels for that return.

### What are the rate limits for the Happy Returns API?

Happy Returns does not publish a public per-second rate limit; partner accounts are throttled per agreement. Build clients to back off on HTTP 429. For high-volume integrations, contact the Happy Returns partner team to confirm sustained throughput.

### How do I create a return through Jentic?

Search Jentic for 'create a happy returns return', load the schema for POST /returns, and execute with the orderId and items. Jentic injects the bearer API key from the vault. Run pip install jentic and use the async client.search, client.load, and client.execute pattern.

### Does the Happy Returns API list Return Bar drop-off locations?

Yes. GET /return-bars lists Return Bars with location and hours, and GET `/return-bars/{returnBarId}` returns the full record for a single bar. Use these to surface the nearest drop-off to a shopper based on their ZIP.

### Does Happy Returns handle the refund payment itself?

POST `/returns/{returnId}/refund` processes the refund against the original payment method as configured for the brand. Happy Returns does not act as a separate payment processor; the underlying refund still flows through the original payment partner.

### Can I limit what my agent is allowed to do with the Happy Returns Partner API?

Yes. Because you run Jentic One yourself, your own rules decide which Happy Returns operations and credentials the agent may use. Happy Returns puts the return id in the URL path, such as `/returns/{returnId}/refund`, so you can pin the agent to a single return and let it read and label that return only. You choose the operations it may call, so state-changing ones like POST `/returns/{returnId}/approve` and POST `/returns/{returnId}/refund` stay out of reach unless you add them.
