Get started
Help / Policies and legal

API and platform terms of service

Terms for developers using the API and external integrations.

These terms set out the conditions for using the Pulse API, webhooks, MCP server and integrations with external services (together, “the platform”) provided by UNCHAIN, Inc. (“we”). They are aimed at developers who retrieve Pulse data from their own systems or scripts, and at administrators who design and run integrations.

These terms are a template

These terms are a template written around a typical way of offering an API. Settle the provisions against how UNCHAIN, Inc. actually offers its API (which plans it is available on, the authentication method, the actual rate limits, whether webhooks exist, whether a sandbox is offered, and so on). In particular, the rate limits in Article 7, the notice period in Article 13 and the measures in Article 15 need to be replaced with the figures and procedures used in practice.

APICreating API keys, access scopes, and revoking themMCP serverLetting conversational AI tools read your notesList of integrationsWhat data each integration sends externallyTerms of serviceThe body of the contract

Article 1 (Purpose and scope)

  1. The purpose of these terms is to set out the rights and obligations between us and developers in relation to use of the platform.
  2. These terms apply from the moment an API key or a workspace API key is issued until every such key has been revoked.
  3. Where the contract to use the service ends, or where the workspace's paid plan ends on cancellation and eligibility to use the platform is lost, the API keys for that workspace are revoked. The cancellation procedure and when it takes effect are as set out in Article 10 of the terms of service and in About cancellation.
  4. These terms constitute standard terms of contract under the Civil Code.

Article 2 (Definitions)

  1. Developer means a person who uses the platform to develop or operate a program, for themselves or for the organisation they belong to.
  2. API key means an identification code we issue to authenticate access to the platform, and includes both personal API keys and workspace API keys.
  3. Access scope means the range of notes an API key can read.
  4. Integrating application means a program or service a developer builds or operates using the platform.
  5. End user means an individual who uses an integrating application.
  6. Data obtained means notes, transcripts, meeting events, participant information and other information a developer obtains through the platform.

Article 3 (Relationship to the other terms, and order of precedence)

  1. In addition to these terms, the terms of service and the privacy policy apply to use of the platform. Where the platform is used together with the desktop app or a browser extension, the application terms of service also apply.
  2. The terms of service are the body of the contract for use of the service; these terms are special provisions supplementing them in respect of matters specific to the platform.
  3. Where these terms, the terms of service and the application terms of service conflict or are inconsistent, the following order of precedence applies.
  4. An individual contract concluded between us and the contracting party
  5. Those provisions of these terms concerning API key management, access scopes, rate limits, the handling of data obtained and other matters specific to the platform
  6. The terms of service
  7. The remaining provisions of these terms
  8. Articles 26 and 27 of the terms of service apply mutatis mutandis to governing law and jurisdiction in the event of a dispute.

Article 4 (Eligibility)

  1. The platform may be used only by members of a workspace on a plan we designate.
  2. A workspace administrator may restrict the access scopes permitted to members. An API key containing an access scope the administrator has not permitted cannot be issued.
  3. Developers are to use the platform having obtained any approval required under the rules of the organisation they belong to.

Article 5 (Responsibility for API keys)

  1. An API key is a credential that can read the notes and transcripts within its access scope. Developers are to keep API keys secure at their own risk.
  2. A developer must not do any of the following with an API key.
  3. Write it into source code, a repository, an issue tracker, a chat tool, a shared document or anywhere else a third party could view it
  4. Embed it in a client application, a script running in a browser or any other program running on a user's device
  5. Disclose, lend or transfer it to anyone other than the person it was issued to
  6. Developers are to store API keys in environment variables or a secrets management system, and to limit who has access to them.
  7. Where an API key may have become known to a third party, the developer is to revoke that key immediately, issue a new one and notify us.
  8. Access made using an API key is deemed to be use by the person it was issued to. Liability for loss arising from misuse by a third party rests with the developer, except where we have acted intentionally or with gross negligence.

Issuing keys, choosing access scopes and revoking them are explained in API.

Article 6 (Access scope and least privilege)

  1. Developers are to choose the narrowest access scope needed to achieve the purpose of the integrating application.
  2. Developers are to issue separate API keys for separate purposes, and to revoke keys promptly once they are no longer needed.
  3. We may change the access scope categories and the range of notes each covers. Where we do, we give the notice set out in Article 13.

Article 7 (Rate limits and load)

  1. The platform has rate limits per API key. Requests above the limit may be refused.
  2. On reaching a rate limit, developers are to retry using exponential backoff, and must not place excessive load on our infrastructure through repeated retries.
  3. When retrieving large volumes of data, developers are to make proper use of incremental retrieval, pagination and caching.
  4. Where we consider it necessary for the stable operation of the platform, we may change the rate limit values or temporarily tighten the limits on a particular API key.
About the rate limit values

The current rate limits are given in API. When designing an integration, check the behaviour under burst conditions as well as the steady-state values. Settle the operational values against how UNCHAIN, Inc. actually offers the service.

Article 8 (Handling data obtained)

  1. Rights in data obtained belong to the user or contracting party who stored that data in Pulse. Use of the platform does not transfer any rights in the data obtained to the developer.
  2. Developers are to use data obtained only to the extent needed to achieve the purpose of the integrating application.
  3. Data obtained will normally contain personal data including participants' names, email addresses and what they said. Developers are to comply with the Act on the Protection of Personal Information and other laws when handling it.
  4. Developers are to establish in advance where data obtained is stored, for how long, who has access to it and how it is disposed of.
  5. Developers must not use data obtained for training machine learning models or for any other purpose different from the purpose for which it was obtained, unless the user or contracting party concerned has consented.
LegislationAct on the Protection of Personal Information, Article 27, paragraph 1 (restriction on provision to third parties) / Article 28 (restriction on provision to third parties in foreign countries)

Providing personal data to a third party requires the individual's prior consent as a rule. Where the recipient is a third party in a foreign country, information about that country's personal data protection regime must as a rule be provided in addition to obtaining consent. Where you design an arrangement that stores data obtained in a system outside Pulse and then passes it to another business, check whether these provisions apply.

LegislationAct on the Protection of Personal Information, Article 23 (security control measures) / Article 25 (supervision of processors)

There is an obligation to take necessary and appropriate measures for the security of personal data, including preventing its leakage, loss or damage, and an obligation to exercise necessary and appropriate supervision over a processor where the handling of personal data is entrusted to one. Where you outsource the operation of an integrating application, you must select the processor carefully, conclude a contract and keep track of how it handles the data.

Article 9 (Disclosure to end users)

  1. Where a developer provides an integrating application to end users, the developer is to disclose the following in a form end users can readily see.
  2. What information the integrating application obtains from Pulse
  3. The purposes for which that information is used
  4. Where that information is stored, and for how long
  5. Where the information is provided to third parties, that fact and who the recipients are
  6. Contact details for enquiries
  7. Developers must not present an integrating application as though it were provided by us.
  8. Developers must not use our trade marks in the name, logo or other presentation of an integrating application without our prior written consent.

Article 10 (No redistribution or resale)

  1. Developers must not sell, lend or redistribute data obtained to third parties without our prior written consent.
  2. Developers must not provide access to the platform itself to third parties, nor provide to third parties for a fee a service of which the platform is a principal component, unless separately agreed with us.
  3. The preceding two paragraphs do not prevent a developer using data obtained within their own organisation for that organisation's business.

Article 11 (Prohibited conduct)

  1. The prohibitions in Article 12 of the terms of service apply mutatis mutandis to use of the platform. The conduct listed in that article (including circumventing access controls, obtaining other users' identification codes, and sending advertising email without the recipient's consent) is prohibited when carried out through the platform as well.
  2. In addition to the preceding paragraph, a developer must not do any of the following.
  3. Obtain, or attempt to obtain, data beyond their access scope
  4. Use an API key issued to another developer or another user
  5. Send large numbers of malformed requests for the purpose of analysing the platform's specification
  6. Send, through an integrating application, email for advertising or promotional purposes to contacts obtained from the platform without the recipient's consent
  7. Use the platform to develop a service that competes with Pulse
LegislationAct on Regulation of Transmission of Specified Electronic Mail, Article 3, paragraph 1 (restrictions on sending specified electronic mail)

Email sent as a means of advertising or promotion may only be sent to people who have consented in advance, who have given you their own email address, who are in a business relationship with you, and the like. Someone who has merely attended a meeting is not normally within those categories. Where you design an integrating application that emails meeting participants, check whether this provision applies.

Article 12 (Webhooks)

  1. For endpoints registered as webhook destinations, developers are to verify the authenticity of what they receive using the signature we provide.
  2. A webhook may be sent more than once for the same event. Developers are to implement a mechanism that does not process the same event twice.
  3. Where a destination endpoint continues not to respond, we may stop sending to it.

Article 13 (Changes to the specification and discontinuation)

  1. We may change the platform's specification (endpoints, parameters, response formats, rate limits, access scope categories and so on).
  2. Where we make a backwards-incompatible change or discontinue a particular feature, we will as a rule give notice at least 90 days before the date of the change or discontinuation, by publishing it in the developer documentation and sending notice to registered email addresses.
  3. Notwithstanding the preceding paragraph, where urgent action is needed for security reasons, we may change the specification or suspend a particular feature without prior notice. In that case we will give notice of what was done and why promptly afterwards.

Article 14 (Audit and investigation)

  1. We collect and retain access records per API key, to the extent needed for the secure operation of the platform.
  2. Where we suspect a breach of these terms, we may ask a developer to explain the structure of their integrating application, how they handle data obtained and other necessary matters. Developers are to cooperate to a reasonable extent.

Article 15 (Measures on breach)

  1. Where a developer breaches these terms, or where we reasonably consider there is a risk of a breach, we may take any of the following measures.
  2. Tighten the rate limits on the API key concerned
  3. Temporarily suspend the API key concerned
  4. Revoke the API key concerned
  5. Withdraw eligibility to use the platform
  6. Suspend use of the service or terminate the contract under the terms of service
  7. Where we take a measure under the preceding paragraph, we will notify the developer of the reason, unless doing so would risk prejudicing an investigation or there is other good reason not to.
  8. A developer may object to us in respect of a measure under the preceding paragraph.

Article 16 (Disclaimer and limitation of liability)

  1. We do not warrant any particular availability, response time or accuracy of results for the platform, except where a service level agreement has been made between us and a contracting party.
  2. The scope and cap of our liability in relation to use of the platform are as set out in Article 17 of the terms of service. Paragraph 1 of this article does not relieve us of liability beyond what that article provides.
  3. Where a developer's breach of these terms causes loss to us or to a third party, the developer is to compensate for that loss.

Article 17 (Changes to these terms)

We may change these terms following the procedure in Article 20 of the terms of service. Where we do, we will publish the reason for the change and what has changed on this page.

LegislationCivil Code, Article 548-4 (change of standard terms of contract)

A party who prepared standard terms may change the contents of the contract without individual agreement where the change is in the general interest of the other party, or where it does not conflict with the purpose of the contract and is reasonable in light of the need for it and other circumstances. In that case, the party must set a date on which it takes effect and, before that date, make known that the terms are being changed, what they will say, and when it takes effect.

Supplementary provisions

  1. These terms take effect on Please contact us.
  2. For enquiries about these terms, contact tharada@the-unchain.com. Vulnerability reports should go to tharada@the-unchain.com in accordance with the vulnerability disclosure policy.

Related articles

← Application terms of serviceTerms of service →
Last updated:14 September 2026