IIndividualPartyManagementPOST Apex Interface

The IIndividualPartyManagementPOST Apex interface provides extensibility for POST operations through Apex pre- and post-hooks and GraphQL query customization. Implementations can validate incoming requests, modify query structures, and refine the response to support business-specific retrieval rules while maintaining TMF-compliant behavior.

This interface supports the following hooks.

transformRequest
configureDefaultValidations
applyCustomValidations
customiseMutationPayload
handlePostOperation

Use Case	Hook(s)	Description	Example Scenarios	Benefit
Default or Normalize Request Fields	`transformRequest`	Transforms the incoming request before validation and mutation processing. It can supply default values, normalize formats, and map client-specific fields to the canonical Account request structure.	- Apply a default Account status or type - Normalize names, phone numbers, and website URLs - Standardize country and region codes - Map legacy fields to TMF632 fields	Ensures consistent, standardized Account data at the point of creation.
Carry Custom Validation Flags	`configureDefaultValidations`	Adds organization-specific validation flags to the validation context. These flags are subsequently read by `applyCustomValidations` to determine which policies should be enforced for the create request.	- Enable duplicate-Account checks - Require tax or registration identifiers - Activate stricter address validation - Require additional checks for regulated Account types	Supports per-organization creation policies by carrying configurable validation flags into custom validation processing.
Enforce Custom Business Rules	`applyCustomValidations`	Reads the configured validation flags and evaluates organization-specific business rules before the Account mutation is built. Invalid payloads are rejected early with an HTTP `400` response and a clear validation message.	- Reject duplicate Accounts based on organization rules - Require registration details for business Accounts - Validate permitted Account types or lifecycle states - Require additional fields for specific regions	Rejects invalid payloads early and prevents inconsistent or noncompliant Account records from being created.
Set Organization-Specific Account Fields	`customiseMutationPayload`	Adds or modifies organization-specific Account fields in the GraphQL mutation payload before execution. This supports fields that extend beyond the standard TMF632 schema.	- Set an internal customer segment - Add a source-system identifier - Populate custom risk or compliance fields - Store organization-specific classification data	Persists custom Account fields beyond the TMF632 data model while preserving the shared API contract.
Audit or Integrate After Creation	`handlePostOperation`	Runs after the Account creation mutation completes and performs post-operation side effects using the creation result. It can write audit records, publish events, or invoke downstream integrations.	- Write an Account-creation audit record - Publish an Account-created event - Synchronize the Account with billing, CRM, or analytics systems - Trigger onboarding or compliance workflows	Enables reliable auditing and downstream processing after successful creation while keeping side effects separate from the core operation.

This hook transforms the request context before processing any operation. It is invoked early in the request lifecycle, allowing implementers to adjust the context for subsequent extensibility hooks.

Map<String, Object> transformRequest(Map<String, Object> context)

Default a missing organizationType and normalize the country code.

This hook enables, disables, or modifies the built-in validation rules before they execute.

Map<String, Boolean> configureDefaultValidations(Map<String, Boolean> defaultValidationConfiguration, Map<String, Object> context)

Add a custom flag consumed by applyCustomValidations.

This hook validates custom business logic before retrieving customer record. If validation fails, it rejects the request and returns an error response.

The handler processes return values as follows.

Success:

Return a map with validationStatus set to “pass” (case-insensitive).
The API request continues normally.
Other fields in the map are logged but not used.

Failure:

Return a map with validationStatus set to “fail” (case-insensitive).
The API request is terminated immediately.
Raise a ValidationException containing
- message: value from validationMessage key (or “Validation failed” by default)
- details: value from validationDetails key (optional)
The client receives an HTTP 400 error response.

Map<String, Object> applyCustomValidations(Map<String, Object> context)

Require an approved organizationType.

This hook modifies the mutation payload before deleting a customer record. Use this to add deletion metadata, set soft-delete flags, or apply business logic transformations.

Map<String, Object> customiseMutationPayload(Map<String, Object> request, Map<String, Object> context)

Add custom Account fields on creation.

This hook post-processes and transforms the API response after data retrieval.

Map<String, Object> handlePostOperation(Map<String, Object> graphQLQueryResultAsMap, Map<String, Object> constructedTMFResponse, Map<String, Object> context)

Publish a platform event after creation.

Here’s a complete sample Apex implementation using all supported hooks.

A TMF632 Individual create payload supports the following input fields:

Scalars:@type (must be Organization), name (required), organizationType.
contactMedium[]: Each item includes an @type discriminator and a corresponding value field:
- PhoneContactMedium → phoneNumber
- FaxContactMedium → faxNumber
- GeographicAddressContactMedium → street1, city, stateOrProvince, postCode, country
relatedParty[]: Each item includes a role, @type, and partyOrPartyRole (id + @referredType).
@referredType = "Individual": Creates an AccountContactRelation, or links Contact.AccountId when Shared Contacts is disabled.
@referredType = "Organization": Creates an AccountAccountRelation. This requires PartyRoleRelation configuration, and the role must match a configured RoleName.

The created Organization, in the same representation returned by GET (relative href, @type = “Organization”, @baseType = “Party”):