ACF Connector Specification — Tripletex
1. Purpose
This specification defines how the ZAYAZ Accounting Connectivity Framework (ACF) integrates with Tripletex.
Tripletex is treated as a source accounting platform rather than merely as a file-import source. The preferred ZAYAZ integration is therefore API-native and preserves source-system identity, permissions, object relationships, provenance and change history from ingestion through ESG calculation and reporting.
The connector is intended to enable Tripletex accounting and operational data to participate safely in:
- ESG screening and emissions estimation;
- invoice- and transaction-level classification;
- supplier and customer resolution;
- project and department allocation;
- evidence collection;
- reporting prepopulation;
- audit and assurance workflows;
- regulatory data-quality assessment; and
- continuous or recurring sustainability data operations.
The connector does not make Tripletex accounting data equivalent to ESG evidence merely because the data exists in an accounting system.
Instead, ACF determines:
- what Tripletex actually provides;
- what the connected customer has authorized ZAYAZ to access;
- what the data can reliably establish;
- what ZAYAZ may derive from it;
- what requires additional evidence; and
- how every resulting calculation or reporting value remains traceable to its source.
2. Connector model
The Tripletex connector is an API-native cloud accounting connector.
The preferred production architecture is:
Tripletex
│
├── REST API / OpenAPI
│ │
│ ├── Initial synchronization
│ ├── Targeted source retrieval
│ └── Periodic reconciliation
│
└── Webhooks
│
└── Incremental change signals
│
▼
ZAYAZ API Hub
│
▼
TrustGate
│
▼
ACF Processing
│
┌───────────┼────────────┐
▼ ▼ ▼
FOGE MICE ZARA
│ │ │
└───────────┼────────────┘
▼
Governed ESG data
The API is the authoritative retrieval mechanism.
Webhooks are treated as change notifications, not as a complete independent source of record.
Periodic API reconciliation therefore remains mandatory for production connections.
3. Integration principles
3.1 Source-native before derived
Where Tripletex provides a source value directly, ZAYAZ preserves that value as the source-native representation.
Any normalization, classification, mapping, allocation, enrichment or ESG calculation is recorded separately.
For example:
Tripletex posting
↓
Source-native amount
↓
Currency normalization
↓
Spend classification
↓
GHG category mapping
↓
Emission-factor resolution
↓
Calculated tCO2e
The calculated result does not replace the accounting source record.
3.2 Stable source identity
Tripletex object IDs should be retained wherever available.
ZAYAZ should not reconstruct relationships by relying on names such as:
- supplier name;
- customer name;
- project name;
- department name;
- account description; or
- product description
when a stable Tripletex object relationship exists.
The minimum source identity is:
Tripletex company
+ object type
+ object ID
For multi-company or accountant connections, the company context is part of the identity.
3.3 Permission-aware capability
Tripletex API capability and customer-accessible data are not the same thing.
A field may be:
supported by Tripletex API
│
├── customer module enabled?
│
├── token owner authorized?
│
├── API token entitled?
│
└── object accessible?
▼
effective connector capability
Consequently:
A missing API value must not automatically be interpreted as missing business data.
ZAYAZ must distinguish:
- API unsupported;
- customer module unavailable;
- token permission unavailable;
- field genuinely empty;
- object genuinely absent; and
- data available through another source.
4. Authentication
Tripletex uses session-token based API authentication.
ACF recognizes two primary integration patterns.
4.1 Commercial ZAYAZ integration
This is the preferred production model for ZAYAZ.
The connection uses:
ZAYAZ consumer token
+
customer employee token
↓
Tripletex session token
↓
authorized API operations
The employee token represents the customer's authorization of the integration.
Effective permissions depend on the permissions available to both the token and its owning user.
ZAYAZ must therefore validate effective access during connector activation rather than assuming that creation of a token grants complete accounting access.
Secrets must be stored only in the approved ZAYAZ secrets infrastructure.
They must never appear in:
- application logs;
- TrustGate event payloads;
- source snapshots;
- telemetry;
- user-visible diagnostics; or
- audit exports.
4.2 Internal integration model
Tripletex also supports an integration model for a single company or company group using a Tripletex-generated refresh credential exchanged for session tokens.
ACF may support this for controlled implementations, development or enterprise-specific deployment models.
It is not the preferred generic ZAYAZ SaaS onboarding model.
4.3 Accountant-client access
Tripletex can expose client companies through accountant access.
This creates an important ACF requirement.
A connection is not identified merely by:
Tripletex token
but by:
Tripletex connection
+
Tripletex company context
+
ZAYAZ tenant
+
ZAYAZ E-C-O Number
ZAYAZ must resolve that context before data is accepted into the canonical model.
No data from one accounting client may be permitted to enter another client's context.
5. Test and production environments
Tripletex provides distinct test and production environments.
Credentials are environment-specific.
ACF therefore treats:
TEST
and:
PRODUCTION
as separate connector environments.
A successful test connection does not itself prove:
- production credentials;
- production permissions;
- identical customer configuration;
- identical enabled modules; or
- production data availability.
Before production activation ZAYAZ should perform a production preflight using the actual authorized production connection.
6. Schema discovery and connector profiling
Tripletex exposes its current API contract through OpenAPI.
ACF uses that API contract together with customer-specific access information to create an:
ACF-TRIPLETEX-CUSTOMER-PROFILE
The profile records the effective capabilities of that customer connection.
6.1 Preflight process
The connector should:
- authenticate;
- resolve the Tripletex company context;
- inspect the current API contract;
- identify relevant endpoints;
- identify available fields;
- identify nested object relationships;
- identify effective token entitlements;
- identify enabled customer capabilities where determinable;
- identify filtering mechanisms;
- identify field-projection mechanisms;
- identify operational retrieval limits;
- discover currently supported webhook events;
- register the API/schema snapshot;
- validate canonical mappings; and
- generate the customer connector profile.
This prevents assumptions such as:
“Tripletex supports invoices, therefore every ZAYAZ Tripletex connection exposes every invoice field.”
That conclusion would be unsafe.
7. Supported accounting data
The Tripletex API provides a materially richer source than a general-ledger-only interchange file.
Depending on the customer's configuration and permissions, ACF may obtain data from domains including:
- accounts;
- postings;
- vouchers;
- customers;
- suppliers;
- invoices;
- supplier invoices;
- orders;
- order lines;
- products;
- projects;
- departments;
- employees;
- VAT and tax structures;
- currencies;
- open accounting items; and
- supported document/archive relationships.
This allows ZAYAZ to move beyond pure account-based ESG estimation.
For example:
Ledger only
↓
Account 6540
↓
Generic spend classification
may become:
Invoice
↓
Supplier
↓
Order line
↓
Product / description
↓
Project / department
↓
More specific classification
The latter may materially improve calculation quality.
8. Financial transactions
Ledger postings are valid inputs for:
- financial reconciliation;
- spend-based screening;
- Scope 3 screening;
- cost allocation;
- entity reconciliation;
- supplier-resolution workflows; and
- evidence discovery.
They are not automatically physical ESG activities.
A posting of:
NOK 48,000
does not prove:
1,200 litres diesel
unless the physical quantity is independently available and validated.
This distinction is governed by the ACF data-quality hierarchy.
9. Customers and suppliers
Tripletex customer and supplier objects should be retained as source master-data identities where available.
Supplier identity is particularly valuable for ESG because it can support:
- supplier-specific classification;
- supplier-country lookup;
- supplier questionnaire routing;
- due-diligence workflows;
- primary-data requests;
- supplier-specific emission factors;
- spend aggregation;
- Scope 3 supplier analysis; and
- evidence linkage.
However:
Supplier identity does not itself constitute supplier-specific ESG data.
Supplier-specific environmental information must still meet the applicable evidence and quality requirements.
10. Invoices, orders and line detail
Invoice, order and line-level data can materially improve ESG classification compared with general-ledger data alone.
Potential classification inputs include:
- supplier;
- customer;
- product;
- description;
- quantity;
- unit;
- unit price;
- VAT treatment;
- currency;
- project;
- department; and
- related accounting objects.
Where sufficient activity information exists, ZAYAZ may be able to upgrade from a spend-based calculation to a more specific method.
For example:
DQ1
NOK 120,000 posted to travel
↓
spend-based factor
may become:
DQ2
individual travel invoices
↓
better classification
and potentially:
DQ3
distance / passenger-km / fuel / nights
↓
activity-based calculation
ZAYAZ must not manufacture this progression when the required source fields do not exist.
11. Projects and departments
Projects and departments can provide allocation dimensions for ESG data.
Examples include:
- construction project footprint;
- customer project emissions;
- operating-site allocation;
- business-unit allocation;
- departmental travel;
- project procurement;
- project profitability combined with sustainability impact; and
- product or contract lifecycle analysis.
A Tripletex dimension is not automatically equivalent to a ZAYAZ semantic dimension.
The relationship must be mapped.
Example:
Tripletex department 104
"Oslo Operations"
↓
ACF dimension mapping
↓
ZAYAZ organizational unit
↓
E-C-O scoped sustainability context
Mapping versions must be preserved.
12. VAT, currency and accounting semantics
Accounting values should be interpreted within their source accounting context.
ACF must preserve or resolve, where applicable:
- source currency;
- reporting currency;
- gross/net amount semantics;
- VAT type;
- accounting date;
- posting period;
- account;
- customer or supplier ledger relationship; and
- source object relationships.
Currency conversion used for ESG calculations is a ZAYAZ transformation and must be recorded separately from the Tripletex-native amount.
Likewise, VAT handling must not be inferred merely from account names or transaction descriptions when authoritative source fields exist.
13. ESG calculation model
Tripletex provides source accounting and business data.
It does not determine the ZAYAZ ESG methodology.
The ESG flow is therefore:
Tripletex
│
▼
Source transaction / invoice / activity
│
▼
ACF canonical mapping
│
▼
Classification
│
▼
Method selection
│
▼
Emission-factor resolution
│
▼
MICE calculation
│
▼
TrustGate lineage
This separation is fundamental.
Accounting software answers:
What business transaction occurred?
ZAYAZ determines:
What sustainability meaning can validly be derived from it?
14. Spend-based emissions
Tripletex is well suited to spend-based emissions screening because it can provide structured financial transactions and potentially additional context such as:
- supplier;
- account;
- invoice;
- order line;
- product;
- project; and
- department.
A typical calculation chain is:
Tripletex posting
↓
supplier / account / line classification
↓
spend category
↓
currency and reference-year normalization
↓
approved EEIO / spend factor
↓
tCO2e estimate
Such a result remains ACF-DQ1 unless more specific evidence supports a higher quality tier.
15. Activity-based emissions
Activity-based calculation is permitted only when the required physical activity is available.
Examples include:
- kWh;
- litres;
- kg;
- tonnes;
- km;
- passenger-km;
- tonne-km; or
- another method-approved activity unit.
An invoice containing:
Electricity
NOK 30,000
does not by itself prove energy consumption.
An invoice or linked evidence containing:
Electricity
12,450 kWh
may support an activity-based calculation if the remaining method requirements are satisfied.
Where the accounting source is incomplete, ACF requests enrichment.
16. Data enrichment
Tripletex data may be combined with other governed ZAYAZ sources.
Examples include:
Tripletex
+
supplier portal
+
electronic invoice
+
invoice PDF
+
meter data
+
logistics data
+
approved factor dataset
The resulting ESG object retains the provenance of every contributing source.
An enrichment does not alter the original Tripletex record.
17. Data-quality hierarchy
ACF applies the common five-level accounting data-quality hierarchy.
ACF-DQ1 — Accounting-only estimate
Typical source:
- account;
- posting;
- spend;
- supplier; and
- transaction text.
Typical use:
- screening;
- spend-based estimation; and
- materiality discovery.
ACF-DQ2 — Invoice-level data
Typical source:
- invoice;
- order line;
- product;
- invoice document; and
- structured supplier relationship.
This may improve category resolution substantially.
ACF-DQ3 — Activity data
Physical activity quantity and unit are available.
Examples:
- 8,500 kWh;
- 740 litres;
- 12 tonnes;
- 4,200 km.
This may support activity-based methodology.
ACF-DQ4 — Supplier-specific data
The relevant supplier provides data attributable to the actual good, service or relationship.
This may include:
- product carbon footprint;
- supplier-specific emission intensity;
- primary activity data; or
- validated supplier disclosure.
ACF-DQ5 — Verified primary data
Primary data has undergone the required validation or verification.
This is the highest ACF quality tier.
18. Quality upgrades
The data-quality model is intentionally progressive.
A calculation can evolve:
DQ1
Accounting spend estimate
│
▼
DQ2
Invoice-level estimate
│
▼
DQ3
Activity calculation
│
▼
DQ4
Supplier-specific result
│
▼
DQ5
Verified primary result
When higher-quality evidence becomes available, ZAYAZ may calculate a new result.
It must not delete the previous result.
The lineage should show:
Result v1
DQ1
↓ superseded by
Result v2
DQ3
↓ verified as
Result v3
DQ5
This is essential for auditability.
19. Webhook architecture
Tripletex supports native webhook subscriptions for selected object events.
ACF should use them for production incremental synchronization where the required event exists.
The connector must dynamically discover the current event catalogue.
It must not assume that a static list embedded in this specification will remain complete.
The operating pattern is:
Initial API sync
│
▼
Webhook subscriptions
│
▼
Incremental changes
│
▼
Durable ZAYAZ event processing
│
▼
Periodic reconciliation
Webhook consumers must be:
- idempotent;
- duplicate-safe;
- retry-safe;
- tenant-scoped;
- legal-entity scoped; and
- traceable.
20. Webhooks are not the source of truth
Webhook delivery can indicate that a source object changed.
It does not remove the need for API reconciliation.
ZAYAZ must not assume:
- every API object has a corresponding event;
- every intermediate version will be delivered;
- event arrival order equals source-change order; or
- a webhook payload represents the complete historical state.
For material ESG data, the authoritative current state should therefore be reconcilable against the Tripletex API.
21. API retrieval efficiency
Tripletex supports filtering and field selection.
ACF should use these capabilities aggressively.
Instead of retrieving a broad object set and discarding most of it later:
GET everything
↓
filter inside ZAYAZ
the connector should prefer:
source filters
+
required field projection
↓
minimum necessary source payload
This reduces:
- API load;
- network traffic;
- processing cost;
- unnecessary personal or financial data ingestion; and
- synchronization latency.
Large collection retrievals must be partitioned using meaningful source-side filters.
22. Canonical mapping
Tripletex data is transformed into the ZAYAZ canonical model.
Examples:
Tripletex account
→ financial.account
Tripletex posting
→ financial.posting
Tripletex supplier
→ organization.supplier
Tripletex customer
→ organization.customer
Tripletex order
→ sales.order
Tripletex order line
→ sales.order_line
Tripletex project
→ project.project
Canonical mapping enables downstream ZAYAZ engines to operate without embedding Tripletex-specific semantics in every calculation or reporting component.
23. Processing pipeline
The canonical ACF processing sequence is:
AUTHENTICATE
↓
RESOLVE COMPANY CONTEXT
↓
RETRIEVE
↓
REGISTER SOURCE
↓
VALIDATE
↓
MAP
↓
NORMALIZE
↓
CLASSIFY
↓
ENRICH
↓
CALCULATE
↓
LINK EVIDENCE
↓
PUBLISH GOVERNED OUTPUT
Each material transformation must be versioned.
24. Classification
Classification may use multiple signals.
For example:
Account
+
Supplier
+
Invoice line
+
Product
+
Description
+
Project
+
Department
↓
classification engine
↓
candidate ESG activity/category
The presence of several signals can materially increase confidence.
However, classification remains a derived ZAYAZ result.
It must not be represented as a Tripletex-native classification unless Tripletex supplied that classification explicitly.
25. Evidence linkage
Accounting records may act as evidence or as pointers to evidence.
Examples:
- invoice record;
- voucher;
- order;
- supplier;
- product;
- accounting posting;
- document relation;
- invoice document; and
- project relationship.
TrustGate governs the evidence chain.
A reporting value may therefore resolve through:
ESRS / VSME datapoint
↓
ZAYAZ result
↓
MICE execution
↓
classified activity
↓
Tripletex invoice line
↓
Tripletex invoice
↓
Tripletex supplier
↓
source object IDs / evidence
This is preferable to exposing the final ESG number without its accounting origin.
26. VSME and ESRS prepopulation
Tripletex can supply useful underlying information for sustainability reporting.
It cannot independently satisfy an entire sustainability reporting standard.
FOGE may use validated ACF data to prepopulate supported fields.
For example:
Tripletex electricity invoice
↓
validated activity
↓
approved calculation
↓
emissions result
↓
eligible reporting datapoint
However, Tripletex accounting records do not by themselves establish areas such as:
- climate policies;
- transition plans;
- sustainability targets;
- workforce policies;
- governance structures;
- due-diligence processes;
- biodiversity policies;
- stakeholder engagement; or
- narrative disclosures.
FOGE must therefore distinguish:
available from Tripletex
from:
required by regulation
and:
eligible for automatic population
27. ZARA behavior
ZARA can use the Tripletex connector specification to explain:
- whether a source field is likely available;
- whether a customer permission is required;
- why enrichment is needed;
- why two calculations differ;
- what source transaction produced a value;
- what data-quality tier applies; and
- whether a value is Tripletex-native or ZAYAZ-derived.
ZARA must never collapse:
source fact
and:
derived interpretation
into one indistinguishable statement.
28. FOGE behavior
FOGE uses ACF metadata to determine:
- source availability;
- prepopulation eligibility;
- evidence sufficiency;
- source preference;
- missing evidence; and
- required enrichment.
Example:
Reporting requirement
↓
required evidence profile
↓
Tripletex capability
↓
available?
│
┌──┴──┐
yes no
│ │
validate request evidence
│
quality threshold met?
│
populate
29. MICE behavior
MICE receives governed inputs rather than raw assumptions.
A calculation request should identify:
- source record;
- calculation method;
- source amount or activity;
- currency if applicable;
- unit if applicable;
- classification;
- emission factor;
- factor version or vintage;
- organization context;
- reporting period; and
- data-quality state.
This allows MICE to reproduce the calculation deterministically.
30. COSE behavior
COSE can compare available Tripletex-derived evidence with regulatory and methodological requirements.
Example:
Requirement:
physical electricity consumption required
Available:
Tripletex invoice spend only
Result:
evidence gap
COSE should not convert:
data exists
into:
requirement satisfied
without testing the evidence requirement.
31. DaVE behavior
DaVE monitors connector reliability and source-data quality.
Relevant signals include:
- authentication failure;
- entitlement change;
- schema change;
- API failure;
- reconciliation mismatch;
- webhook failure;
- supplier-resolution failure;
- missing currency;
- unexplained null values;
- orphaned object relationships; and
- unexpected financial or ESG variance.
A connector can therefore remain technically online while still being marked degraded for ESG purposes.
32. TrustGate behavior
TrustGate preserves the chain between:
Tripletex source
↓
ACF transformation
↓
classification
↓
calculation
↓
reporting output
↓
verification
The lineage must survive:
- recalculation;
- enrichment;
- source correction;
- accounting-period reopening;
- methodology change;
- emission-factor replacement;
- manual override; and
- verification.
33. Closed-period changes
Accounting systems may receive:
- late postings;
- corrections;
- reversals;
- reopened periods; and
- payment or reconciliation changes.
A change to historical accounting data can affect previously calculated ESG results.
ACF must therefore detect relevant historical changes.
A change does not automatically overwrite a published result.
Instead:
source mutation
↓
lineage event
↓
affected ESG objects identified
↓
revalidation
↓
recalculation if governed policy requires
The previous state remains auditable.
34. Security
The Tripletex connector must implement:
- encrypted transport;
- encrypted secret storage;
- tenant isolation;
- legal-entity isolation;
- least privilege;
- token and entitlement controls;
- authenticated webhook callbacks;
- audit logging;
- connection monitoring; and
- strict test/production separation.
Secrets must never be stored as ordinary connector metadata.
35. Data minimization
The API's ability to constrain requests should be used as part of ZAYAZ privacy and security design.
ACF should retrieve:
the minimum source data required for the approved processing purpose.
For example, an ESG calculation that requires:
- posting ID;
- amount;
- date;
- account;
- supplier; and
- project
should not automatically retrieve unrelated employee or customer information.
This is both an efficiency and governance control.
36. Limitations
The Tripletex connector has important limitations.
36.1 Accounting data is not complete ESG data
Tripletex is an accounting and business system.
It should not be expected to contain all sustainability information required by ZAYAZ.
36.2 Physical activity may be absent
Financial transactions can identify expenditure without identifying physical consumption.
Additional evidence may therefore be required for activity-based calculations.
36.3 Permission affects visibility
An unavailable field may indicate insufficient authorization rather than absence of the data.
36.4 Customer configuration varies
Tripletex modules and company configurations vary between customers.
Connector capability must therefore be profiled per connection.
36.5 Webhook coverage is not universal
Webhook support must be dynamically discovered and supplemented with API reconciliation.
36.6 API schemas evolve
OpenAPI changes may affect mappings.
Schema snapshots and mapping versions must therefore be governed.
36.7 Accounting classifications are not ESG classifications
Account number, supplier or product name alone must not be treated as conclusive ESG categorization.
37. Recommended production architecture
The recommended production deployment is:
TRIPLETEX
│
┌────────────┴────────────┐
│ │
REST API WEBHOOKS
│ │
│ │
└────────────┬────────────┘
▼
API HUB
│
connection profile
│
▼
TRUSTGATE
│
source lineage
│
▼
ACF
┌───────────────┼─────────────────┐
│ │ │
normalize validate classify
│ │ │
└───────────────┼─────────────────┘
▼
CANONICAL DATA MODEL
│
┌─────────────┼──────────────┐
│ │ │
MICE FOGE ZARA
│ │ │
└─────────────┼──────────────┘
▼
GOVERNED ESG OUTPUTS
A scheduled reconciliation process operates alongside this architecture.
38. Quick-start implementation
For a controlled pilot:
- create a Tripletex test connection;
- establish authentication;
- generate the customer connector profile;
- ingest a limited historical accounting period;
- map accounts, suppliers, invoices, projects and departments;
- validate source identity and relationships;
- run ESG screening;
- compare DQ1 versus available DQ2 inputs;
- verify lineage;
- test relevant webhook subscriptions; and
- reconcile source objects against Tripletex.
The pilot should not be treated as production-ready until permission, reconciliation, failure handling and lineage controls are validated.
39. Production implementation
Production should add:
- approved commercial integration credentials;
- governed customer activation;
- least-privilege entitlement templates;
- automated schema inspection;
- customer connector profile generation;
- durable webhook processing;
- reconciliation scheduling;
- operational monitoring;
- schema-drift detection;
- TrustGate registration;
- data-quality diagnostics; and
- controlled recalculation.
40. Accountant and white-label use case
Tripletex's accountant-client model is strategically relevant to ZAYAZ.
A future accounting partner could potentially operate:
Accounting firm
│
├── Client A Tripletex
├── Client B Tripletex
├── Client C Tripletex
└── Client D Tripletex
│
▼
ZAYAZ ACF connection layer
│
▼
separate E-C-O contexts
The connection may be operationally shared while tenant data, permissions, evidence and ESG outputs remain fully isolated.
This model could support:
- sustainability services by accounting firms;
- VSME reporting;
- Scope 3 screening;
- financed-emissions data preparation;
- supplier ESG services;
- auditor-ready evidence packages; and
- white-label ZAYAZ deployments.
No shared accountant connection may weaken tenant-level isolation.
41. Connector activation gate
A Tripletex connection should not become active until the following minimum gate passes:
Authentication PASS
Company context PASS
Token entitlement validation PASS
Schema/API snapshot PASS
Canonical mapping PASS
Tenant isolation PASS
TrustGate registration PASS
Initial reconciliation PASS
Required monitoring PASS
Webhook functionality may additionally be required for the selected production profile.
42. Definition of done
The Tripletex connector is production-ready when ZAYAZ can demonstrate that it can:
- authenticate securely;
- resolve the correct company context;
- inspect and register the active API contract;
- determine effective source permissions;
- retrieve required accounting objects;
- preserve Tripletex source IDs and relationships;
- map those objects into the canonical model;
- normalize and validate them deterministically;
- process supported webhook events safely;
- reconcile webhook-derived state against the API;
- detect relevant historical source changes;
- execute ESG screening without inventing missing activity;
- upgrade calculations when better evidence becomes available;
- retain prior calculations and provenance;
- support FOGE, ZARA, MICE, COSE and TrustGate consumers;
- prevent cross-tenant and cross-company data leakage;
- detect API or mapping drift; and
- reproduce any material ESG result from source to output.
43. Source references
The connector specification is based primarily on current official Tripletex developer material covering:
- API and developer documentation;
- OpenAPI documentation;
- authentication and token models;
- test and production environments;
- integration best practices;
- webhooks;
- general API behavior;
- invoice and order behavior; and
- supplier-invoice workflows.
The live Tripletex OpenAPI contract remains authoritative for endpoint and field-level implementation.
The ACF connector profile must therefore be regenerated or reviewed when a material Tripletex API change affects:
- endpoints;
- field definitions;
- authorization;
- webhook events;
- source relationships; or
- synchronization behavior.
Runtime Provider Extension
The provider-specific runtime contract for this connector is maintained separately from the common ACF connector frontmatter.
It contains machine-actionable provider semantics that are intentionally not part of the common ACF schema, including authentication lifecycle, provider object revision semantics, change-capture constraints and provider-specific capability rules.
schema_id: zayaz.acf.provider-extension.v1
extension_version: 1.0.0
connector_id: ACF-TRIPLETEX
provider:
namespace: tripletex.tripletex
name: Tripletex
product: Tripletex
runtime:
source_contract:
primary_api: rest_v2
openapi_supported: true
production_and_test_credentials_separate: true
source_identity:
company_context_required: true
local_source_ids_preserved: true
object_revision:
source_revision_preserved_separately_from_change_cursor: true
query:
filter_supported: true
fields_projection_supported: true
large_result_partitioning_required_above_rows: 10000
change_capture:
webhook:
supported: true
role: freshness_signal
authoritative_payload: false
reconciliation:
required: true
synchronization:
preferred_sequence:
- initial_sync
- webhook_signal
- authoritative_reread
- reconciliation
source_semantics:
project:
candidate_id_class: EBP
automatic_resolution_allowed: false
quantity:
activity_status: candidate
requires_unit_and_business_semantics: true
evidence:
source_record_lineage_required: true
extensions:
authentication_flow:
integration_consumer_and_employee_token_to_session_token: true
internal_session_refresh_required: true
governance:
status: active
last_verified: 2026-08-30
review_interval_days: 90
change_control_required: true
source_basis: connector_specification