The Actuarial Certificate integration is bi-directional. While the API Reference documents the callback endpoints your system POSTs to on Class, this page documents the request that Class POSTs to your endpoint when a user requests a certificate.
You must host an HTTPS endpoint (registered with Class) that accepts this request and returns an acknowledgement.

When a user requests a certificate, Class POSTs the fund data to your registered endpoint. The payload conforms to the Actuarial Certificate Request Data Standard (v1.0).
The standard is the source of truth for the payload structure, field definitions, and enumerations. Refer to:

• Standard overview & schema: https://accurium.github.io/actcertstd/ea-diagram
• Worked examples with sample data:
  • Deemed segregation: https://accurium.github.io/actcertstd/example1-deemed-seg
  • Elected segregation: https://accurium.github.io/actcertstd/example2-elected-seg

Class sends the request as XML by default. The format (XML or JSON) is agreed per provider during onboarding; Class sets the Content-Type and Accept headers to match your configured format. Your endpoint parses this payload and returns an acknowledgement.

Your endpoint must respond synchronously. Return a Response object to accept the request, or a ResponseStatus object to reject it — the two cases are documented separately below.

Return a Response containing the response URL and, optionally, a draft percentage:

JSON

{
    "Response": {
        "Url": "https://your-service.example/certificate/review?ref=8f3a2b...",
        "Percentage": 63.18
    }
}

XML

<ActuarialCertificateResponseInfo>
    <Response>
        <Url>https://your-service.example/certificate/review?ref=8f3a2b...</Url>
        <Percentage>63.18</Percentage>
    </Response>
</ActuarialCertificateResponseInfo>

To reject a request, populate the ResponseStatus error fields. Class treats a response as errored if either field contains a message. Ideally, populate both fields:

Populate DisplayError with a clear, user-friendly message and Error with any technical detail that will help Class troubleshoot. Each field is a list, so you can supply more than one message:

JSON

{
    "ResponseStatus": {
        "DisplayError": [
            "We could not process this fund because the member details are incomplete. Please review and resubmit."
        ],
        "Error": [
            "Validation failed: Member[2].DateOfBirth is null; unable to compute ECPI."
        ]
    }
}

XML

<ActuarialCertificateResponseInfo>
    <ResponseStatus>
        <DisplayError>We could not process this fund because the member details are incomplete. Please review and resubmit.</DisplayError>
        <Error>Validation failed: Member[2].DateOfBirth is null; unable to compute ECPI.</Error>
    </ResponseStatus>
</ActuarialCertificateResponseInfo>

The response URL is provider-owned — Class does not generate it or enforce a format. Class validates only that it is non-empty, stores it, and surfaces it to the requesting user so they can review and finalise.

The identifiers you'll need for the callback endpoints are taken from the initial request payload:

• Authenticate the caller if required (mechanism agreed during onboarding).
• Persist the RequestId, BusinessCode, FundCode, and financial year — you'll need these for the callbacks.
• Calculate (or begin calculating) the ECPI%.
• Return a response URL for the Class user to review and finalise.
• Once finalised, call back to Class to create a status, optionally update it, and upload the certificate PDF — see Provider-to-Class Updates.

• Callback endpoints your system POSTs to Class — see the API Reference.
• The status lifecycle — see Workflow.
• How to obtain a bearer token — see Authentication.