## Actuarial Certificate — Overview

The Actuarial Certificate integration is a two-way integration between Class and an approved Actuarial Certificate Provider (ACP). It enables a Class administrator to request an actuarial certificate for a fund directly from Class, and allows the provider to send the calculated exempt current pension income (ECPI) percentage and the signed certificate document back to Class until the request is complete.

Unlike a standard consumer API, the Actuarial Certificate integration involves calls in **both directions**:

- **Class → Provider** — Class initiates the request by POSTing the fund data to a URL you host.
- **Provider → Class** — Your system calls back to Class REST endpoints to create/update the certificate status and upload the certificate document.


Because of this, becoming an ACP partner requires:

- Registering an HTTPS endpoint that Class can call with the fund data.
- Building the ability to call Class's callback endpoints using OAuth 2.0.


This documentation covers the **Post-2018** REST/OAuth integration, which applies to financial years **FY2018 onward**. The legacy pre-2018 flow is not covered.

### What Class allows users to do

- Select and configure an Actuarial Certificate Provider for a fund.
- Request an actuarial certificate for a fund for a specific financial year (from Periodic Processing → Period Updates).
- Review the returned ECPI% on the provider's website and finalise.
- Store the returned percentage and the certificate document (PDF) against the fund.


All certificate requests are for **one financial year for one fund**. Bulk requests are not supported.

### High-level flow

1. A Class user runs period updates for a full financial year, selects your firm as the provider, and requests a certificate.
2. Class POSTs the fund data to **your** registered endpoint.
3. Your system acknowledges with a response URL and, optionally, a draft percentage.
4. Class surfaces the response URL to the user, who follows it to your website to review the ECPI% and finalise / pay.
5. Once finalised, your system calls back to Class to **create a status** (endpoint A), optionally **update it** (endpoint B), and **upload the certificate PDF** (endpoint C).


**Payload format:** Class sends the initial request as **XML by default**. XML or JSON is agreed per provider during onboarding, and your acknowledgement follows the same format. See [Class-to-Provider Requests](/products/class/apis/actuarial-provider/class-to-provider).

**Certificate status:** each status you post carries a label of **Interim** or **Final**. You can post multiple updates; **Final** is the label Class users treat as complete. See [Workflow](/products/class/apis/actuarial-provider/workflow) for the detail on how this behaves.

### What lives where in this documentation

| Section | What it covers |
|  --- | --- |
| **Registration** | The information you provide to Class, and what Class issues to you, before you can integrate. |
| **Authentication** | How to obtain a bearer token to call the Class callback endpoints. |
| **Workflow** | The Interim / Final status lifecycle and the typical call sequences. |
| **Class-to-Provider Requests** | The payload format Class sends to *your* endpoint, and the acknowledgement you return. |
| **Provider-to-Class Updates** | The three callback endpoints you POST to on Class (create status, update status, upload document). |
| **API Reference (Actuarial Certificate)** | The callback endpoints with full schemas and examples. |


### Environments

| Environment | API host |
|  --- | --- |
| Partner Integration (Sandbox) | `apigateway.class-pie.com.au` |
| Production | `apigateway.class.com.au` |


Your integration is built and demonstrated against PIE first. Once Class has verified the integration and a partnership agreement is in place, you will be promoted to production.