generated: '2026-07-25' method: derived source: openapi/ (5 OpenAPI 3.0.1 documents) + https://developer.pplnextgen.com/Get-Started/Base-API-Standard searched: - https://developer.pplnextgen.com/Get-Started/Authentication-Information - https://developer.pplnextgen.com/Get-Started/Reference-Architecture - https://placingplatformlimited.com/api-integrations/ - https://placingplatformlimited.com/the-core-placing-platform/ note: >- Every `conforms` value below is backed by evidence taken either from the harvested specifications or from a page PPL publishes. Where PPL asserts a standard in marketing material but it is not traceable in the machine-readable artifacts, that is recorded explicitly rather than accepted. standards: - id: openapi-3.0 conforms: true evidence: 'All five published documents declare openapi: 3.0.1 and parse cleanly.' - id: rest conforms: true evidence: >- The Base API Standard mandates resource-oriented URIs, plural collection nouns, method semantics (GET must not modify state, PUT must be idempotent, PATCH unsupported, HEAD supported) and HTTP status semantics. The shipped specs follow it. - id: oauth2 conforms: true evidence: >- Documented (not in-spec). Microsoft Entra ID authorization-code, on-behalf-of and client-credentials flows, with the scp claim user_impersonation required by the LIMOSS API Gateway. See https://developer.pplnextgen.com/Get-Started/Authentication-Information. caveat: No securityScheme of type oauth2 is declared in any of the five OpenAPI documents. - id: oidc conforms: true evidence: >- The portal's reference implementation uses OpenID Connect against https://login.microsoftonline.com/ with ResponseType "code id_token" and CallbackPath /signin-oidc. caveat: >- No OIDC discovery document is served on any PPL or gateway host — /.well-known/openid-configuration returns 404 everywhere probed. - id: rfc8414-authorization-server-metadata conforms: false evidence: /.well-known/oauth-authorization-server returns 404 on all five probed hosts. - id: mutual-tls conforms: true evidence: >- "Mutual HTTPS required: X.509 client certificate (CN identifies application)" (Base API Standard); a distinct certificate must be registered per API Gateway environment. - id: rfc9457-problem-details conforms: false evidence: >- Errors use a custom application/json envelope (components.schemas.error_document — an errors[] array of {code, message, field, argument}), not application/problem+json. No type/title/status/ detail/instance members are present. - id: rfc7807-problem-details conforms: false evidence: Same as RFC 9457 — no problem+json media type anywhere in the five documents. - id: rfc9110-http-semantics conforms: true evidence: >- Status-code usage follows HTTP semantics — 400/401/404/414/429/500 declared on every business operation; the standard additionally names 403, 409 and 503. - id: rfc6585-additional-status-codes conforms: true evidence: 429 Too Many Requests is declared on all 57 business operations. - id: retry-after-throttling conforms: partial evidence: >- The Base API Standard requires Retry-After with 429 and 503, but no Retry-After response header is declared in any of the five OpenAPI documents. - id: rfc7232-conditional-requests conforms: partial evidence: >- The standard mandates optimistic concurrency control via If-Match / If-Unmodified-Since and ETag / Last-Modified. The shipped APIs implement the precondition as a custom X-Last-Modified request header on all 10 update operations; no ETag or If-Match parameter is declared. - id: rfc8594-sunset-header conforms: false evidence: No Sunset or Deprecation header is documented or declared; no deprecation policy is published. - id: rfc9116-security-txt conforms: false evidence: /.well-known/security.txt returns 404 on all five probed hosts. - id: iso8601-dates conforms: true evidence: >- "Date: ISO 8601 / XSD:date (e.g. 2008-10-31); DateTime: ISO 8601 / XSD:dateTime" — Base API Standard; date and date-time formats are used throughout the specs. - id: rfc1123-http-dates conforms: true evidence: The standard requires the Last-Modified header in RFC 1123 format. - id: acord-grlc conforms: asserted evidence: >- "Built using REST standards and ACORD GRLC data model" — https://placingplatformlimited.com/api-integrations/. PPL also runs a live ACORD Solutions Group ADEPT Placing data-exchange gateway in production (AXA XL, announced 2 December 2025), which ACORD describes as "supporting alignment with ACORD Global Reinsurance & Large Commercial (GRLC) Standards". caveat: >- The string "ACORD" does not appear anywhere inside the five harvested OpenAPI documents, nor on the portal's Get-Started or Technical Model pages. The alignment is a published claim and a real production integration; it is NOT traceable in the machine-readable contract, so no field-level ACORD GRLC class mapping can be asserted. - id: lloyds-blueprint-two conforms: true evidence: >- PPL is one of the accredited placing platforms in the Lloyd's / London Market Blueprint Two programme and generates the Core Data Record for business bound on the platform. caveat: Programme participation, not a certifiable technical conformance profile. - id: fapi conforms: false evidence: No FAPI profile is claimed or implied; this is not an open-banking style surface. - id: psd2 conforms: false evidence: Not applicable — PPL is (re)insurance placement infrastructure, not a payments provider. - id: fhir-r4 conforms: false - id: scim2 conforms: false - id: odata conforms: false - id: json-api conforms: false evidence: Responses use a plain resource envelope with page_number/page_size/count/total_results, not the JSON:API document structure. - id: hateoas conforms: false evidence: >- The Base API Standard specifies a links structure with first/last/prev/next relations on collections, but no such structure appears in any of the five documents. - id: asyncapi conforms: false evidence: >- No event-push surface of any kind. No AsyncAPI document, no webhooks, no callbacks object in any of the five specs. The Events API is strictly pull-based REST. - id: graphql conforms: false - id: grpc conforms: false compliance_program: published: false certifications: [] note: >- No trust centre, no SOC 2, ISO 27001, PCI DSS or equivalent certification statement was found on placingplatformlimited.com, developer.pplnextgen.com or www.pplnextgen.com, and probe-security-programs.py returned no verified trust-centre or vulnerability-disclosure hit. Because PPL publishes no compliance programme, no `Compliance` pointer is emitted in apis.yml. PPL is a UK company (Placing Platform Limited, England and Wales, company no. 08350117) and publishes a privacy notice, so UK GDPR applies as law rather than as a published certification. related: conventions: conventions/ppl-london-market-conventions.yml authentication: authentication/ppl-london-market-authentication.yml errors: errors/ppl-london-market-problem-types.yml domain_security: security/ppl-london-market-domain-security.yml