Policy: Moodle™ – Third Party Integrations

Policy: Moodle™ Third-Party Integrations

Last updated: 23 July 2026

1. Purpose

This policy sets out the conditions under which Pukunui may assess, configure, develop, connect, maintain and support third-party integrations involving a Client’s Moodle™ site.

Third-party integrations can extend the functionality of Moodle™ and facilitate the exchange of information with external systems. They may also introduce additional security, privacy, data-quality, compatibility, availability, licensing, support and operational risks.

This policy should be read together with:

The applicable Moodle™ Support Agreement, hosting agreement, proposal or statement of work.
Pukunui’s Moodle™ Third-Party Plugins Policy.
Any applicable data-processing, privacy, security or project-specific agreement.

Where there is any conflict between this policy and a signed agreement between Pukunui and the Client, the signed agreement will take precedence.

2. Definitions

For the purposes of this policy:

Client means the person or organisation receiving hosting, support, development or other Moodle™ services from Pukunui.

External Service means any system, platform, application, infrastructure or service outside the Client’s Moodle™ site that is connected to or exchanges information with the site.

Integration Component means any plugin, custom code, middleware, API client, scheduled task, script, data feed, webhook, database connection or other technical component used to implement a TPI.

MSA means the Moodle™ Support Agreement or other applicable support or services agreement between Pukunui and the Client.

Pukunui means Pukunui Technology in Australia, Pukunui Limited in Hong Kong, Pukunui Sdn Bhd in Malaysia, and their employees, contractors and authorised service providers.

Third-Party Integration or TPI means a connection between a Client’s Moodle™ site and an External Service that allows authentication, data exchange, automated actions or access to external functionality.

TPI Provider means the individual or organisation responsible for developing, supplying, operating, licensing, maintaining or supporting an External Service or Integration Component.

A TPI remains a third-party integration whether it is obtained through Moodle Marketplace, supplied directly by a provider, developed by another contractor, operated by the Client or accessed through another platform.

3. Scope

This policy applies to existing and proposed TPIs, including:

Single sign-on and external authentication services.
Student, school, university, human resources and information-management systems.
Course, enrolment and user-provisioning systems.
Payment gateways, ecommerce systems and subscription platforms.
Document-management and content-storage services.
Plagiarism-detection and academic-integrity services.
Artificial intelligence and automated assessment services.
Proctoring and identity-verification services.
Video-conferencing and communication platforms.
Analytics, reporting and business-intelligence services.
Customer relationship management systems.
Credential, certification and digital-badge services.
Data warehouses and data-lake platforms.
External mobile applications.
Data exchange through APIs, web services, webhooks or middleware.
Direct database connections.
Scheduled file imports or exports.
Custom integrations developed by Pukunui, the Client or another provider.

A TPI may rely on one or more third-party Moodle™ plugins. Where this occurs, both this policy and Pukunui’s Third-Party Plugins Policy apply.

4. Third-party status

An External Service or Integration Component supplied by a TPI Provider is controlled by that provider.

Unless expressly agreed otherwise in writing, Pukunui is not:

The developer, owner, operator or licensor of the External Service.
The merchant or reseller responsible for its sale.
A party to the agreement between the Client and the TPI Provider.
Responsible for the TPI Provider’s infrastructure, services, personnel or business practices.
Responsible for setting or controlling its prices, licence terms, service limits or release schedule.
Responsible for the TPI Provider’s product-level support.
Responsible for the TPI Provider’s privacy, security or data-handling practices.

The TPI Provider is responsible for the functionality, availability, security, licensing, documentation, maintenance and support of its External Service and any Integration Components it supplies.

Pukunui cannot require a TPI Provider to maintain, update, repair or continue supplying an integration or service.

Configuring or assisting with a TPI does not mean that Pukunui endorses, certifies or assumes responsibility for the TPI Provider or its services.

5. Requesting an integration

Requests to assess, configure, develop or modify a TPI must be submitted to Pukunui through an approved support or project channel.

The Client should provide, where available:

The name and business purpose of the integration.
The systems to be connected.
The intended direction of data flow.
The categories of information to be exchanged.
The expected frequency and volume of transactions.
The party responsible for each connected system.
Contact details for the TPI Provider.
Technical and API documentation.
Authentication and authorisation requirements.
Required permissions and access levels.
Data-field definitions and mapping requirements.
Privacy and data-processing documentation.
Security documentation or certifications.
Data-hosting and storage locations.
Retention and deletion requirements.
Service limits, rate limits and usage quotas.
Required licences, subscriptions or supplier accounts.
Test accounts, sandbox access or sample data.
The required implementation timeframe.
Relevant service-level or availability requirements.

Pukunui may request additional information before beginning an assessment or implementation.

Pukunui may decline to assess or implement a TPI where sufficient documentation, technical access, provider cooperation or security and privacy information is unavailable.

6. Integration ownership

The Client must nominate an appropriate owner for each TPI.

The integration owner is responsible for:

Confirming the business purpose of the TPI.
Coordinating decisions within the Client organisation.
Approving data mappings and workflows.
Coordinating with the TPI Provider.
Arranging user-acceptance testing.
Approving the production deployment.
Monitoring whether the integration continues to meet the Client’s requirements.
Informing Pukunui of relevant changes or incidents.

Where an integration involves multiple Client departments or service providers, the Client must identify an authorised decision-maker.

Pukunui is not responsible for resolving disputes between the Client, its departments, its users or its other service providers concerning ownership or operation of a TPI.

7. Technical assessment

Pukunui may approve a TPI based on prior experience with the relevant service, provider, Integration Component and technical environment.

For other TPIs, Pukunui may perform a limited technical and operational assessment before approving implementation.

The scope of an assessment may include:

The proposed integration architecture.
The connection and data-transfer method.
Authentication and authorisation controls.
Required accounts, credentials and permissions.
API or web-service documentation.
Data flows and data destinations.
Data validation and sanitisation controls.
Encryption and transport security.
Error handling and retry behaviour.
Duplicate and conflict handling.
Logging and audit capabilities.
Performance and resource usage.
Rate limits and service quotas.
Compatibility with the Client’s Moodle™ environment.
Conflicts with existing plugins or integrations.
Scheduled tasks and background processes.
The TPI Provider’s documentation and support arrangements.
The availability of test environments.
Rollback, recovery and reconciliation requirements.
Known security, maintenance or reliability concerns.

Any assessment performed by Pukunui is limited to the documentation, systems, code, access and information available at the time.

An assessment is not:

A comprehensive source-code audit.
A penetration test.
A guarantee that the TPI is free from defects or vulnerabilities.
A legal or regulatory assessment.
A privacy impact assessment.
An accessibility audit or certification.
A financial or procurement review.
A guarantee of the TPI Provider’s availability or future performance.
A guarantee of continued compatibility.

Assessment work may be chargeable where it falls outside the MSA or requires substantial investigation, development or consultation.

8. Assessment outcomes

Following an assessment, Pukunui may:

Approve the TPI for implementation.
Approve the TPI subject to specified technical or operational conditions.
Require a proof of concept, pilot or staging implementation.
Identify revisions required before implementation.
Provide a quotation for configuration, remediation or development.
Recommend an alternative integration method or provider.
Decline to implement the TPI.
Require an existing TPI to be restricted, redesigned, suspended or removed.

Pukunui may decline a TPI where it reasonably considers that the TPI presents an unacceptable:

Security risk.
Privacy or data-protection risk.
Data-integrity risk.
Stability or performance risk.
Compatibility risk.
Legal or licensing risk.
Operational or support burden.
Risk to Pukunui’s infrastructure or other clients.

Approval applies only to the assessed configuration, environment and version.

Material changes to the External Service, Integration Component, data flow, authentication method or connected systems may require reassessment.

9. Client responsibilities

Before requesting or approving a TPI, the Client is responsible for determining whether the integration is appropriate for its business, educational, technical and legal requirements.

The Client is responsible for:

Defining the intended business outcome.
Confirming that the External Service is suitable.
Reviewing the TPI Provider’s contractual terms.
Maintaining valid licences, subscriptions and supplier accounts.
Paying all TPI Provider fees.
Obtaining internal procurement, security, legal and management approval.
Determining whether the proposed data processing is lawful.
Providing appropriate privacy notices and obtaining any required consent.
Reviewing the TPI Provider’s privacy and security practices.
Determining the appropriate source of truth for integrated data.
Approving all data mappings and transformation rules.
Providing accurate configuration information.
Maintaining a relationship with the TPI Provider.
Arranging cooperation from its other service providers.
Providing suitable testing personnel and test data.
Completing user-acceptance testing.
Approving production deployment.
Monitoring the integration’s business results.
Reporting errors or discrepancies promptly.
Informing Pukunui of relevant provider, service or contractual changes.

The Client must ensure that any instructions supplied to Pukunui are authorised by an appropriate representative of the Client.

10. TPI Provider cooperation

The Client is responsible for obtaining the necessary cooperation from its TPI Provider.

Pukunui may require the Client to arrange:

Access to current technical documentation.
Access to a test or sandbox environment.
Technical meetings with the provider.
Clarification of undocumented behaviour.
Assistance troubleshooting provider-side issues.
Confirmation of supported software versions.
Confirmation of security and privacy controls.
Notification of planned API or service changes.
Access to provider support services.
Escalation of faults within the External Service.

Pukunui is not responsible for project delays caused by a TPI Provider’s failure to provide timely information, access or assistance.

Additional work resulting from incomplete, inaccurate or changed provider documentation may be chargeable.

11. Fees, licences and subscriptions

TPI Provider charges are not included in the MSA unless expressly stated otherwise.

The Client is responsible for:

Licence and subscription fees.
Usage-based charges.
API fees.
Transaction fees.
Storage or data-transfer charges.
Premium supplier-support plans.
Renewal fees.
Applicable taxes.
Fees charged by middleware or other connected services.

Pukunui is not responsible for a loss of functionality caused by:

An expired or suspended licence.
Failure to renew a subscription.
A failed payment.
Exhausted usage credits.
An exceeded service limit or quota.
A change in the TPI Provider’s prices or terms.
Suspension or termination of the Client’s supplier account.

Where Pukunui agrees to purchase or administer a service on the Client’s behalf, the ownership, payment, renewal and transfer arrangements must be documented in writing.

Pukunui is not required to purchase, renew or maintain a third-party account unless this responsibility is expressly included in an agreement.

12. Data ownership and systems of record

Before production deployment, the Client must define which connected system is the authoritative source of each category of information.

The integration design should identify:

The owner of each data category.
The system of record.
The direction in which data will be transferred.
Whether data may be updated in one or both systems.
The frequency of synchronisation.
The rules for resolving conflicting information.
The treatment of duplicate records.
The treatment of deleted or suspended records.
The handling of historical records.
The process for correcting errors.
The process for reconciling failed or incomplete transactions.

Pukunui is not responsible for deciding which Client system should be treated as authoritative unless this is expressly included in an agreed consultancy scope.

A TPI may reproduce errors contained in a source system. Pukunui does not guarantee the accuracy, completeness or suitability of information supplied by the Client, its users, its TPI Provider or another connected system.

13. Data mapping, validation and sanitisation

The Client is responsible for approving all data fields, mappings, transformations and business rules.

Pukunui may implement validation, sanitisation, formatting and transformation rules where these are included in the agreed scope.

Unless expressly agreed otherwise, Pukunui is not responsible for:

Inaccurate source data.
Incomplete records.
Duplicate records.
Incorrect identifiers.
Invalid field values.
Unexpected formatting.
Malicious or untrusted data supplied by another system.
Data that does not conform to the TPI Provider’s documentation.
Changes to the structure or meaning of provider data.

Where malformed, inaccurate or unsafe information threatens the site or integration, Pukunui may reject, quarantine or stop processing affected transactions.

Additional work required to clean, repair, deduplicate, reconcile or restore data may be chargeable.

14. Privacy and data protection

A TPI may allow an External Service to access, collect, transmit, modify, store, analyse or delete information from the Client’s Moodle™ site.

This may include:

User identity and profile information.
Authentication information.
Course and enrolment records.
Assessment results and submissions.
Communications and activity records.
Payment information.
Analytics and usage information.
Personal, confidential or sensitive information.

The Client is responsible for determining whether the proposed use of the TPI complies with applicable:

Privacy and data-protection laws.
Employment requirements.
Education-sector requirements.
Records-management requirements.
Data-residency requirements.
Contractual confidentiality obligations.
Organisational privacy and security policies.

Before approving the TPI, the Client should review:

The TPI Provider’s privacy policy.
The purposes for which data will be used.
The data-hosting and processing locations.
International data transfers.
Data-retention and deletion practices.
Subprocessors and associated services.
Security controls.
Breach-notification arrangements.
Contractual data-processing terms.
Processes for exercising data-subject rights.

Pukunui’s technical assessment, assistance or implementation does not constitute legal, privacy or regulatory approval.

Unless separately commissioned, Pukunui is not responsible for:

Completing a privacy impact assessment.
Determining the lawful basis for processing.
Obtaining consent.
Preparing privacy notices.
Negotiating a data-processing agreement with the TPI Provider.
Auditing the provider’s legal compliance.

Pukunui may decline or suspend a TPI where adequate privacy or data-processing information is unavailable or where the TPI presents an unacceptable risk.

15. Security

The TPI Provider is responsible for the security of its External Service and any Integration Components it supplies.

The Client is responsible for assessing the TPI Provider’s security arrangements and determining whether they satisfy the Client’s requirements.

Pukunui may require appropriate controls, including:

Encryption for information in transit.
Secure authentication methods.
Separate service accounts.
Least-privilege access.
Restricted API permissions.
Multi-factor authentication where supported.
Secure storage of credentials.
Credential rotation.
IP-address restrictions.
Time-limited access tokens.
Signed or verified webhook requests.
Audit logging.
Rate limiting.
Appropriate timeout and retry controls.

Credentials, tokens, certificates and private keys must not be sent through insecure channels.

Pukunui may refuse to implement a TPI that requires:

Shared personal accounts.
Plain-text credentials.
Unencrypted transfer of sensitive information.
Excessive system permissions.
Unrestricted direct database access.
Unsupported or insecure authentication methods.
Security controls that Pukunui considers inadequate.

16. Accounts, credentials and access

Where possible, integration access should use dedicated service accounts rather than accounts assigned to individual users.

The Client is responsible for:

Authorising creation of required accounts.
Approving the permissions granted to each account.
Maintaining current account-owner information.
Informing Pukunui when access should be changed or revoked.
Maintaining recovery and administrative access to its external services.
Ensuring credentials are not shared with unauthorised parties.

Unless expressly agreed otherwise, the Client should retain ownership and administrative control of all external supplier accounts.

Pukunui may retain credentials securely where required to provide an agreed service.

Pukunui may rotate, revoke or disable credentials where it reasonably considers this necessary to protect the Client, Pukunui’s infrastructure or other services.

17. Authentication and single sign-on

Where a TPI provides authentication or single sign-on, the Client is responsible for approving:

The users who may authenticate.
Account-matching and account-creation rules.
Required identity attributes.
Domain and tenant restrictions.
Multi-factor authentication requirements.
User suspension and deprovisioning rules.
The treatment of renamed or duplicate accounts.
The process for handling identity-provider outages.

Pukunui may require that the Moodle™ site retain a restricted local administrative account for emergency access.

The Client is responsible for maintaining administrative and recovery access to its identity provider.

Pukunui is not responsible for a loss of access caused by an unavailable, misconfigured or suspended external identity service, except to the extent that the issue was caused by Pukunui’s failure to deliver an expressly agreed service.

Restoring access or reconciling accounts following an identity-provider issue may be chargeable.

18. Direct database access

Direct database access can present significant security, performance and data-integrity risks.

Pukunui may prohibit or restrict direct database connections to a Moodle™ database.

Where direct access is approved, Pukunui may require:

Read-only access.
Access to a replica or reporting database.
Restricted database accounts.
Network restrictions.
Query limits.
Approved maintenance windows.
Monitoring and logging.
Prior review of queries or workloads.
A separate data-export mechanism.

No third party may write directly to the Moodle™ database without Pukunui’s express written approval.

Pukunui may immediately suspend database access where queries or connections affect performance, security, availability or data integrity.

19. Testing and deployment

Pukunui may require a TPI to be developed, configured or tested in a staging, sandbox or test environment before production deployment.

Implementation may be subject to:

A documented integration design.
Approved data mappings.
Test accounts and representative test data.
Functional testing.
Security testing appropriate to the agreed scope.
Performance or volume testing.
Failure and retry testing.
Duplicate and reconciliation testing.
User-acceptance testing.
A maintenance window.
A current backup.
A rollback plan.
A deployment checklist.
Client approval to proceed.

The Client is responsible for confirming that the TPI meets its business and functional requirements.

Successful testing does not guarantee that the External Service will remain available or that future changes will not affect the integration.

20. Production launch

The Client must authorise production launch after completing appropriate user-acceptance testing.

Where practicable, the Client should verify after launch that:

Expected records have been transferred.
User accounts have been created or updated correctly.
Enrolments and permissions are correct.
Financial or transactional information is accurate.
Failed transactions have been identified.
Duplicate records have not been created.
External notifications have been delivered.
Relevant reports and logs are available.

Pukunui may recommend a limited pilot or phased rollout before full production use.

Additional support during launch or an agreed stabilisation period may be quoted separately.

21. Support

Pukunui will provide support for Moodle™ core in accordance with the applicable MSA.

TPI support is outside the standard scope of the MSA unless expressly included in the relevant agreement, proposal or statement of work.

TPI-related services may include:

Requirements gathering.
Technical consultancy.
Initial configuration.
Development of Integration Components.
Testing and deployment.
Investigation of data-transfer failures.
Troubleshooting authentication issues.
Data reconciliation.
Liaison with the TPI Provider.
Modifying an integration following provider changes.
Migration to another service.
Incident response and recovery.

These services may be quoted and charged separately.

Product-level support for an External Service remains the responsibility of the TPI Provider.

Pukunui may provide occasional advice or assistance with a TPI without creating an ongoing obligation to provide the same service in the future.

Where an incident is caused or materially contributed to by a TPI, time spent identifying, isolating or resolving the issue may be chargeable unless the applicable agreement expressly includes that work.

22. Availability and performance

Pukunui does not control the availability or performance of an External Service.

A TPI may be affected by:

Provider outages.
Internet or network interruptions.
Scheduled provider maintenance.
API latency.
API rate limits.
Usage quotas.
Provider capacity limits.
Authentication failures.
Changes to provider infrastructure.
Regional service restrictions.
Suspension of the Client’s supplier account.

Unless expressly included in a signed agreement, Pukunui does not guarantee an end-to-end service level for a process that depends on an External Service.

Service levels applying to Pukunui’s hosting or Moodle™ services may exclude delays or failures caused by third-party systems.

Where a TPI adversely affects the performance or availability of the Moodle™ site, Pukunui may throttle, pause, restrict or disable it.

23. Changes and compatibility

Pukunui does not guarantee that a TPI will remain compatible with:

Future versions of Moodle™.
Future versions of PHP, the database, operating system or infrastructure.
Future versions of an Integration Component.
Changes to the TPI Provider’s API.
Changes to authentication requirements.
Changes to data structures or field definitions.
Changes to rate limits or service quotas.
Changes to another installed plugin or integration.

The Client must notify Pukunui of planned changes to connected systems where those changes may affect the integration.

Pukunui may reassess a TPI before a Moodle™ or infrastructure upgrade.

Where a TPI is incompatible with a proposed upgrade, Pukunui may:

Postpone the upgrade where it is reasonable and safe to do so.
Recommend changes to the integration.
Recommend replacing or discontinuing the TPI.
Quote for remediation or redevelopment.
Require the Client to accept a temporary loss of integration functionality.
Proceed with an essential security or infrastructure upgrade where postponement would create an unacceptable risk.

Pukunui is not required to delay an essential security update indefinitely because of an incompatible TPI.

24. Monitoring, logs and reconciliation

A TPI should include appropriate monitoring and error reporting where these features are available and included in the agreed scope.

Pukunui may retain technical logs relating to:

Connection attempts.
Authentication events.
Successful or failed transactions.
Error messages.
Processing times.
Scheduled-task activity.
API responses.
Record identifiers.

For privacy and security reasons, logs may not retain complete transaction payloads or sensitive data.

The availability and retention period of logs may vary between systems.

Unless expressly included in an agreement, the Client is responsible for monitoring business outcomes and reconciling records between connected systems.

Pukunui does not guarantee that every failed or incomplete transaction will be automatically detected.

Investigation or reconciliation of historical transactions may be chargeable.

25. Backups and recovery

A backup of the Client’s Moodle™ site may not include information stored in an External Service.

Restoring a Moodle™ backup may create inconsistencies between Moodle™ and a connected system, including:

Duplicate transactions.
Missing transactions.
Repeated notifications.
Conflicting user or enrolment records.
Incorrect synchronisation timestamps.
Reprocessing of previously completed events.

A TPI is not a substitute for an appropriate backup or data-export process.

The Client is responsible for confirming the TPI Provider’s backup, retention, export and recovery arrangements.

Recovery and reconciliation following a restore, provider outage or integration failure may require coordination with the TPI Provider and may be chargeable.

26. Incidents and emergency action

The Client must notify Pukunui promptly if it becomes aware of:

A security incident involving the TPI.
Compromised credentials.
Unexpected data disclosure.
Unauthorised transactions.
Data corruption.
Significant discrepancies between systems.
Malicious or abnormal integration behaviour.
A TPI Provider security notification.

Pukunui may temporarily disable, isolate, restrict or remove a TPI without prior approval where Pukunui reasonably considers this necessary to protect:

The security of the Moodle™ site.
Personal or confidential information.
The integrity of Client data.
The availability of the site.
Pukunui’s hosting infrastructure.
Other clients or services.
Pukunui’s legal or regulatory obligations.

Emergency actions may include:

Pausing data transfers.
Blocking an endpoint.
Disabling an Integration Component.
Revoking or rotating credentials.
Restricting network access.
Disabling a scheduled task.
Temporarily disabling external authentication.

Where reasonably practicable, Pukunui will notify the Client before taking action. In an urgent situation, Pukunui may act first and notify the Client as soon as reasonably practicable afterwards.

Incident investigation, remediation, recovery and data reconciliation may be chargeable in accordance with the applicable agreement.

27. Discontinuation and provider changes

A TPI Provider may:

Discontinue or suspend its service.
Change its API.
Remove features.
Change ownership.
Introduce new fees.
Change its licence or contractual terms.
Change its privacy or data-hosting arrangements.
Stop supporting an Integration Component.
Restrict access to future versions.
Terminate the Client’s account.

Pukunui is not responsible for these decisions.

Where a TPI becomes unavailable, unsupported, incompatible or unsuitable, Pukunui may recommend that it be:

Retained temporarily with documented risks.
Restricted.
Suspended.
Reconfigured.
Replaced.
Redeveloped.
Permanently disconnected.

Any assessment, redevelopment, migration, data export or replacement work may be quoted separately.

Pukunui does not guarantee that a suitable replacement will be available or that all external data can be exported or transferred.

28. Exit planning and data portability

The Client should consider how it will retrieve its information and continue essential operations if a TPI Provider relationship ends.

The Client is responsible for reviewing:

Available data-export formats.
Export charges.
Data-retention periods.
Account-closure procedures.
Provider deletion policies.
Contract-termination requirements.
Dependencies on proprietary identifiers or formats.
The availability of alternative providers.
Manual contingency processes.

Unless expressly included in an agreed scope, Pukunui is not responsible for maintaining a separate copy of information stored exclusively within an External Service.

Migration or exit assistance may be quoted separately.

29. Custom and modified integrations

Custom Integration Components may require ongoing maintenance as Moodle™, the External Service and related infrastructure change.

Custom development may:

Depend on undocumented provider behaviour.
Require modification following API changes.
Require additional testing after upgrades.
Become incompatible with new authentication or security requirements.
Require ongoing monitoring and maintenance.
Depend on continued access to provider test environments.

Pukunui is not obligated to maintain a custom integration indefinitely unless a separate maintenance agreement is in place.

Ownership, licensing, source-code access, documentation, warranties and ongoing maintenance arrangements for custom development should be documented in the applicable proposal or statement of work.

30. Unapproved integrations and changes

Where Pukunui manages the hosting environment or Moodle™ codebase, the Client and its other suppliers must not implement, modify or enable a server-side TPI without Pukunui’s prior approval.

The Client must disclose:

API connections.
Webhooks.
Middleware services.
Scheduled imports or exports.
Direct database connections.
Custom scripts.
External authentication changes.
New service accounts.
Changes made by another supplier.
Integration Components installed outside the standard deployment process.

Where an unapproved TPI causes or contributes to an incident:

Pukunui is not responsible for the resulting disruption, loss or incompatibility except to the extent required under the applicable agreement or law.
Relevant service levels may not apply while the TPI causes or contributes to the incident.
Investigation and remediation work may be chargeable.
Pukunui may require the TPI to be restricted, disabled or removed.
Pukunui may suspend affected services where necessary to protect its systems or other clients.

A material or repeated breach may be managed under the suspension or termination provisions of the applicable MSA rather than automatically voiding the entire MSA.

31. No continuing approval or warranty

Approval, implementation, testing or previous support of a TPI does not create a continuing warranty or obligation.

Pukunui does not warrant that a TPI will:

Meet all of the Client’s requirements.
Operate without interruption or error.
Transfer every transaction successfully.
Remain secure.
Remain available.
Remain supported by its provider.
Remain compatible with future systems.
Remain available at its current price.
Preserve all information during provider or system changes.

Any liability relating to Pukunui’s services remains subject to the applicable MSA and other signed agreements.

32. Policy updates

Pukunui may update this policy to reflect changes in Moodle™, technology, security practices, legal requirements, third-party services or Pukunui’s services.

Where reasonably practicable, Pukunui will notify affected clients of material changes.

The version published on Pukunui’s website will be the current version of this policy unless a signed agreement expressly provides otherwise.

33. Contact

Clients with questions about an existing or proposed TPI should contact Pukunui through their usual support channel.

Pukunui can assist with:

Preparing integration, remediation or migration quotations.
Reviewing proposed integrations.
Documenting integration requirements.
Assessing technical feasibility and risks.
Reviewing currently configured integrations.
Identifying integrations affected by Moodle™ upgrades.
Developing or modifying Integration Components.