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.

This table lists common use cases and the hooks required for the POST operation.

Use CaseHook(s)DescriptionExample ScenariosBenefit
Default or Normalize Request FieldstransformRequestTransforms the incoming request before validation or mutation processing. It can supply default values, normalize formats, and map client-specific fields to the canonical request structure.- Apply a default contact status
- Normalize phone numbers or email addresses
- Standardize country and region codes
- Map legacy fields to TMF632 fields		Ensures consistent, standardized data at the point of creation.
Relax or Tighten Built-In ValidatorsconfigureDefaultValidationsEnables, disables, or adjusts built-in validation flags for create requests according to organization-specific requirements.- Require stricter email or phone validation
- Disable a validator that is not applicable to an internal channel
- Require additional identity checks in regulated organizations
- Apply different validation policies by tenant or environment		Supports per-organization validation policies without modifying the shared create implementation.
Enforce Custom Business RulesapplyCustomValidationsEvaluates organization-specific business and eligibility rules before the create mutation is built. Invalid payloads are rejected early with an HTTP 400 response and a clear validation message.- Prevent duplicate contacts based on organization rules
- Require consent before creating a marketing contact
- Validate permitted customer types or lifecycle states
- Require additional fields for specific regions		Rejects invalid payloads early and prevents inconsistent or noncompliant records from being created.
Set Organization-Specific Contact FieldscustomiseMutationPayloadAdds or modifies organization-specific Contact 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 consent or preference fields
- Store organization-specific classification data		Persists custom Contact fields beyond the TMF632 data model while preserving the shared API contract.
Audit or Integrate After CreationhandlePostOperationRuns after the create mutation completes and performs post-operation side effects using the creation result. It can write audit records, publish events, or invoke downstream integrations.- Write a contact-creation audit record
- Publish a customer-created event
- Synchronize the contact with a downstream CRM or marketing platform
- Trigger onboarding or notification 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 title 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)

Relax the contactMedium validation.

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 a corporate email domain.

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 Contact 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 "Individual"), givenName, familyName, title, and birthDate.

  • contactMedium[]: Each item includes an @type discriminator and a corresponding value field:

    • EmailContactMedium → emailAddress
    • PhoneContactMedium → phoneNumber
    • FaxContactMedium → faxNumber
    • GeographicAddressContactMedium → street1, city, stateOrProvince, postCode, country

  • relatedParty[]: Each item includes a role and a partyOrPartyRole with @type = "PartyRef", @referredType = "Organization", and id set to the Account ID.

    • The first entry sets Contact.AccountId.
    • Additional entries create AccountContactRelation records and require Contacts to Multiple Accounts to be enabled.

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