Terms of Service of the MuninCloud Flexible API

0. Who provides the service

• Company: Bogarra Integrated SL (Spanish limited company), trading as MuninCloud.
• Tax ID (NIF): B13627971.
• Registration: registered in the Commercial Registry (Registro Mercantil) of Ciudad Real, volume (tomo) 659, folio 126, sheet (hoja) CR-30598, 1st entry (inscripción 1ª).
• Registered office: Calle General Aguilera N10 5A, 13001 Ciudad Real, Spain.
• Contact: soporte@munincloud.com · telephone: +34 686 490 850 · data protection: rgpd@munincloud.com.

These terms govern the MuninCloud Flexible Data Processing API (the "API"). They are separate from the terms of the MuninCloud Invoice API and of any other MuninCloud product: a different service, different keys, a different balance and different invoices.

Who may sign up. Businesses, professionals and individuals. Natural persons must be at least 18 years old. If the Customer signs up as a consumer, clause 14 (consumers) also applies.

1. What is offered

1.1. The service. An API in the format of the OpenAI API giving access to two models:

• Qwen3-32B (Qwen/Qwen3-32B-AWQ, 4-bit AWQ quantisation): chat, tool calling, structured output and streaming, through /v1/chat/completions.
• BGE-M3 (BAAI/bge-m3): dense vectors (embeddings), through /v1/embeddings.

The current catalogue, with each model's context length, maximum output, price and location, is the one returned by GET /v1/models. Models are offered only under their real name and, in the catalogue, under their owner's name (Qwen and BAAI), never as MuninCloud models.

1.2. The technical contract. The behaviour of the API (routes, bodies, errors, headers) is the one published in its v1 contract. Within v1 fields may be added, never removed or renamed. Anything not in the contract is not offered.

1.3. Shared capacity. The engine that runs the models is shared by MuninCloud with its own services, which have priority. When they need it, the API yields with 429 and Retry-After instead of queueing the request (the details of each error are those of the technical contract, clause 1.2). The API is not a reserved machine and does not guarantee any specific capacity or availability.

1.4. Reasoning. The model's reasoning (enable_thinking) is off by default. If the Customer turns it on, reasoning tokens are output tokens and are charged as such.

1.5. Third-party models. The models were not developed by MuninCloud: Qwen3-32B is distributed under the Apache 2.0 licence and BGE-M3 under the MIT licence. MuninCloud runs them as they are, without retraining or fine-tuning them. See clause 8.

2. The prepaid balance

2.1. Prepaid in euros. The API is used with a prepaid balance in euros. No request is processed without an available balance. Marketplace accounts follow clause 2.9.

2.2. Top-ups. The balance is topped up in fixed amounts of €10, €25, €50 or €100 (taxes not included). No other amounts are accepted.

2.3. Balance cap. The accumulated balance of an account may not exceed €500. A top-up that, together with what is reserved at that moment by requests in progress, would take the balance above that cap is not accepted.

2.4. Payment. Top-ups are paid in advance, by card, through the Stripe payment gateway. Card details are kept by Stripe; MuninCloud only keeps the payment reference.

2.5. Expiry: exactly 12 months. Each top-up forms a lot that expires exactly 12 months after it is credited to the account: on the same day and at the same time (Madrid time) twelve months later; if that day does not exist in the month (for example, the 31st), on the last day of that month. Usage spends first the lot that expires first. Whatever is left of a lot when it expires expires and is not refunded (except to a consumer: clause 14.9), including any part that was reserved at that instant by a request in progress: if that request ends after the expiry, what it consumes comes out of that lot and whatever is left of its reservation expires; it does not move to another lot. Expiry never makes the balance negative.

2.6. Account closure. A closed account cannot be used again: its balance can no longer be spent. A consumer is refunded the unspent part (clause 14.9). A business or professional is refunded it on request before it expires (clause 2.5). The refund is handled manually, by means of a corrective invoice, by writing to soporte@munincloud.com, and the amount refunded leaves the account balance.

2.7. Refunds. Except in the cases of clauses 2.6, 9.5 and 11 and those of a consumer (clauses 14.2 and 14.9), topped-up balance is not refunded.

2.8. How the contract is concluded. Each top-up is a contract concluded on the API purchase page of the MuninCloud portal, with these steps:

• a) The Customer chooses the top-up amount (clause 2.2) and gives its email address, its country (and its postcode, if in Spain), its name or company name and, if it has one, its NIF or EU VAT number (clause 4).
• b) It enters its card details, which are checked with its bank's authentication (clause 2.4).
• c) Just above the payment button, the page shows the total including taxes, what is being bought, its duration and its expiry (clause 2.5). A consumer also ticks the mandatory box, not ticked in advance, by which they ask for the service to start straight away (clause 14.5); the ticked box is stored with the top-up.
• d) The contract is concluded by pressing the "Pay now (order with obligation to pay)" button.
• e) Once the top-up is charged, the balance is credited to the account; if it is the first one, the Customer receives on the page, and by email, a single-use link to collect its access key (clause 5).

Correcting errors. Until it presses the payment button, the Customer may review and correct on the same page any data it has entered, or abandon the purchase: nothing is charged. If any data is not valid, the page says so and nothing is charged.

Filing and access. MuninCloud files each top-up with its invoice (clause 4.1) and, if the Customer is a consumer, with the ticked box. The Customer has it accessible in the invoice email for each top-up, which confirms the contract and carries the terms in force on that date and, for a consumer, the ticked box. These terms can be downloaded as a PDF, with their date, from this page.

2.9. Marketplaces. Whoever uses the API through a marketplace (OpenRouter or Hugging Face) contracts with the marketplace, under its terms. MuninCloud provides the service to the marketplace, as a business and under a separate contract: its account is not prepaid (clause 2.1) but on credit, with a cap per channel and a monthly invoice, and its rate is in US dollars (USD), invoiced in the currency set at sign-up. That channel only opens as stated in the Privacy Policy (section 5).

3. What each request costs

3.1. Price per token. Each request uses up from the balance the input and output tokens counted by the engine, at each model's price per million tokens published in GET /v1/models at the time of the request. Prices at the date of these terms, excluding taxes:

A consumer is shown, on the pricing page and on the purchase page and before paying, the full final price, including the taxes that apply to them (clause 4.2): per million tokens and for the whole top-up (clause 2.8.c). The balance is drawn down at the tax-exclusive prices of this table because the taxes are paid with the top-up, on its invoice (clause 4.1).

3.2. Reservation and settlement. Before a request is processed, its highest possible cost is reserved (the input tokens plus max_tokens, or the output cap applied by the API if the Customer does not set it). When it ends, the actual cost is charged and the rest of the reservation is returned. If the available balance does not cover the reservation, the request is rejected with 402 (insufficient_quota) and nothing is charged.

3.3. No rounding. The amount of each request is calculated in micro-euros (€0.000001) without rounding: the fraction of a micro-euro left over by each request is carried over in the account and charged when the accumulated fractions reach a whole micro-euro. What is charged is exactly the amount given by the prices in clause 3.1.

3.4. What is not charged. A rejected request (4xx errors) is not charged, nor is one that fails in the engine or in the API (5xx) without having delivered tokens.

3.5. Interrupted streaming. If the Customer cuts a stream midway, the engine stops generating and only what was generated up to the cut is charged. If the API fails midway through a stream, only what was delivered is charged.

3.6. Price changes. A price increase may only be due to one of the reasons in clause 11; it is notified 30 days in advance, by email to the Customer and on this page, and applies to requests made from the announced date, on which it enters GET /v1/models. A price decrease applies to requests made from its publication in GET /v1/models. No price change affects what has already been consumed.

3.7. Checking. The balance, the reserved amount, the account limits and the movements (top-ups, usage and adjustments) can be checked in the API itself (GET /v1/cuenta and GET /v1/cuenta/movimientos), in whole micro-euros.

4. Invoices and taxes

4.1. One invoice per top-up. One invoice is issued for each top-up, when it is paid, in this product's own series. Later usage only lowers the balance and does not generate further invoices.

4.2. Prices exclude taxes. The tax is calculated by the system according to the Customer's country and the tax details provided when topping up:

While Bogarra Integrated SL's sales to private individuals in other Member States remain below the €10,000 annual threshold of the Spanish VAT Act (art. 73), Spanish VAT applies. If it is exceeded, the VAT of the individual's country will apply, at its rate, from the sale that exceeds it.

4.3. VAT number check. The VAT number of a Customer from another EU Member State is checked in VIES, the European Commission's system, at the time of payment. The consultation number returned by VIES is kept as evidence. If VIES cannot answer at that moment, the top-up is not charged and may be retried; if the VAT number is valid but belongs to a country other than the one declared by the Customer, it is not charged until clarified.

4.4. Accuracy of data. The Customer is responsible for its tax details (country, postcode, VAT number) being true. Falsifying them to pay less tax is a serious breach and a ground for closing the account.

5. Access keys

5.1. Format. Keys have the form mf_live_… and are sent in the Authorization: Bearer header. Each key is shown only once, when it is created; MuninCloud only keeps its fingerprint, never the key.

5.2. IP list. A key may optionally be restricted to a list of IP addresses.

5.3. Safekeeping. The Customer is responsible for keeping its keys safe: usage with one of its keys is deducted from its balance. If a key leaks, the Customer must revoke it, or ask for it to be revoked at soporte@munincloud.com, as soon as it knows. To limit the damage of a stolen key, each account has a cap on requests per minute and may have a daily spending cap (clause 6).

6. Usage limits

6.1. Rate. Each account has a maximum number of requests per minute; above it, the API answers 429 (rate_limit_exceeded) with Retry-After.

6.2. Daily spending. An account may have a spending cap per day (UTC); when it is reached, the API answers 402 (spend_limit_reached) until the next day.

6.3. Where to check them. The current limits of each account are shown in GET /v1/cuenta.

6.4. Acceptable use. Use of the API is subject to the Acceptable Use Policy, which forms part of these terms.

7. Content and outputs

7.1. No prompts or responses stored. MuninCloud does not store the content of requests or responses: it is not written to disk or to the logs. Only metadata is recorded (see the Privacy Policy). For that reason MuninCloud cannot recover a lost response.

7.2. Outputs of an AI model. Responses are generated by an artificial intelligence model and may be incorrect, incomplete, made up or inappropriate. The service is an obligation of means: MuninCloud does not guarantee that an output is accurate or fit for a particular purpose, and gives no advice of any kind through the API. The Customer must review outputs before using them, especially in decisions that affect people.

7.3. Ownership and training. The content the Customer sends and the outputs the API returns to it belong to the Customer: MuninCloud claims no rights over them. Neither the content nor the outputs are used to train, fine-tune or improve any model, MuninCloud's or anyone else's.

8. EU Artificial Intelligence Act

8.1. Who does what. MuninCloud makes available to the Customer, through an API, general-purpose AI models developed by third parties (clause 1.5), without modifying them. A Customer that integrates the API into its own system or application is responsible for that system and for the obligations that Regulation (EU) 2024/1689 on artificial intelligence places on it because of it, in particular transparency towards the people who use it (art. 50) and the prohibition of the practices in art. 5.

8.2. Model information and marking of generated content. MuninCloud states in GET /v1/models which model answers, who owns it and where it runs, and in each response the model that generated it, so that the Customer can meet its own information obligations. In addition, each response carries a machine-readable marking (a header and a field, described in the technical contract of clause 1.2) that identifies it as content generated by artificial intelligence (art. 50(2) of Regulation (EU) 2024/1689).

9. Suspension and closure

9.1. MuninCloud may suspend a key or an account, without notice, if it detects use contrary to the Acceptable Use Policy, an attempt to evade charges or limits, or a risk to the security of the service or of third parties.

9.2. It may close the account for a serious breach of these terms. The balance of a closed account is governed by clause 2.6: a consumer is refunded the unspent part (clause 14.9).

9.3. The Customer may close its account at any time by writing to soporte@munincloud.com.

9.4. Automatic blocking. Anomalous or malformed calls in bursts may be taken by the perimeter defence systems as an attack or a scan and cause the source IP to be blocked automatically. Routes that do not exist answer 410 so that a bug in the Customer's program is not mistaken for a scan.

9.5. End of the service. If MuninCloud stops providing the API, it refunds every Customer the unspent part of their balance, whether consumers, businesses or professionals, manually and with a corrective invoice (clause 2.6).

10. Liability

10.1. MuninCloud is not liable for damage resulting from the use of the model's outputs (clause 7.2), from the unavailability of the service due to the priority of its own services (clause 1.3), or from usage with a key the Customer did not keep safe (clause 5.3).

10.2. Cap (businesses and professionals). If a final judgment declared the direct civil liability of Bogarra Integrated SL towards a Customer that signs up as a business or professional, total compensation will be limited to the amount of the top-ups paid by the Customer in the three (3) months before the event that causes it. This cap does not apply in the case of wilful misconduct (dolo, Spanish Civil Code, art. 1102) and does not apply to consumers (clause 14.3).

11. Changes to these terms

The terms in force are those published on this page, with their date. Changes are published here with the date and a summary under "Updates".

MuninCloud may only change these terms for the worse for the Customer (among other changes, by a price increase, clause 3.6) for one of the following reasons, and for no other:

• a) a change in the law, or a decision that binds MuninCloud;
• b) a change in the cost of providing the service (energy, equipment, hosting);
• c) a change in the models offered or in their licence;
• d) security reasons.

Changes that make the Customer's terms worse are notified 30 days in advance, by email to the Customer and on this page, and apply from the announced date; improvements, from their publication. A Customer that does not accept a change may close its account (clause 9.3); its balance is governed by clause 2.6. A consumer (clause 14) who does not accept a change for the worse may close their account and recover the unconsumed part of their balance, at no cost: the refund is handled manually, by means of a corrective invoice, as in clause 2.6.

12. Governing law and jurisdiction

12.1. These terms are governed by Spanish law.

12.2. For businesses and professionals, the parties submit to the Courts of Ciudad Real (Spain). For consumers, the courts of their domicile have jurisdiction (clause 14.3).

13. Language

These terms are published in Spanish and in English. In case of discrepancy, the Spanish version prevails.

14. Consumers (annex)

14.1. Who it applies to. A Customer that signs up as a consumer: a natural person acting for a purpose outside their trade, business, craft or profession; or a legal person or an entity without legal personality acting on a non-profit basis outside a trade or business activity (art. 3.1 of the consolidated text of the Spanish General Law for the Protection of Consumers and Users, "TRLGDCU"). For them, this clause prevails over the others where they conflict.

14.2. Withdrawal from a top-up. A consumer may withdraw from a top-up, without giving any reason, within 14 calendar days from the day the top-up is contracted, which is the day it is charged and credited to the account (TRLGDCU arts. 102.1 and 104.a). To withdraw it is enough to send, before the period expires, an unequivocal statement of the decision, for example an email to soporte@munincloud.com; the model withdrawal form in clause 14.8 may be used, but it is not obligatory (art. 106.1 and 106.2). What has not been consumed of that top-up is refunded (clause 14.5), within the period and by the means of clause 14.6.

14.3. Cap, exclusions and courts. The liability cap of clause 10.2 and the submission to the Courts of Ciudad Real of clause 12.2 do not apply to consumers: the courts of their domicile have jurisdiction (TRLGDCU art. 90.2). The exclusions of clause 10.1 apply to them only insofar as they do not exclude or limit the rights the law gives them for non-performance or defective performance (art. 86.1).

14.4. Their statutory rights. Nothing in these terms limits the rights that consumer law gives the consumer: any prior waiver of them is void (TRLGDCU art. 10).

14.5. Immediate start and what has been consumed. When contracting a top-up, the consumer expressly requests that the service starts at that moment, within the withdrawal period, and acknowledges that, once the contract has been fully performed (the whole top-up consumed), the right of withdrawal will have been lost (TRLGDCU arts. 98.8 and 103.a). If the consumer then withdraws, they pay for the part of the service already provided, which is what has been consumed of that top-up at the prices of clause 3.1 (art. 108.4). Without that express request, a consumer who withdraws bears no cost for the service provided during the withdrawal period (art. 108.5.a).

14.6. The refund. What has not been consumed is refunded without undue delay and in any event before 14 calendar days have passed from the day the consumer communicates the decision to withdraw, using the same means of payment the consumer used (the card), unless the consumer expressly agrees otherwise, and without the refund costing the consumer anything (TRLGDCU art. 107.1). It is handled manually, with a corrective invoice, as in clause 2.6, and the amount refunded leaves the account balance.

14.7. Legal guarantee of conformity. The consumer has the legal guarantee of conformity for digital content and digital services governed by the TRLGDCU (arts. 97.1.n and 114 et seq.).

14.8. Model withdrawal form (annex I.B of the TRLGDCU; complete and return this form only if you wish to withdraw from the contract):

To Bogarra Integrated SL (MuninCloud), Calle General Aguilera N10 5A, 13001 Ciudad Real, Spain, soporte@munincloud.com:
– I/We (*) hereby give notice that I/We (*) withdraw from my/our (*) contract for the provision of the following service: top-up of balance of the MuninCloud Flexible API of ……… €
– Ordered on ………
– Name of consumer(s)
– Address of consumer(s)
– Signature of consumer(s) (only if this form is notified on paper)
– Date

(*) Delete as appropriate.

14.9. Unspent balance, on expiry or closure. A consumer is refunded the unspent part of their balance when a lot expires (clause 2.5) and when their account is closed, whether by them or by MuninCloud (clauses 2.6, 9.2 and 9.3), at no cost to them (TRLGDCU art. 87, paragraphs 4, 5 and 6). It is handled manually, with a corrective invoice and by the same means of payment, and the amount refunded leaves the account balance.

15. Data processing (annex)

15.1. What this annex is. As regards any personal data contained in the content of requests, the Customer is the controller and Bogarra Integrated SL (MuninCloud) is the processor (Privacy Policy, clause 1.1). This clause is the processing contract required by Article 28(3) of Regulation (EU) 2016/679 (GDPR): the Customer accepts it when signing up, together with the rest of these terms, and it binds MuninCloud with regard to the Customer.

15.2. Subject matter, duration, nature and purpose. The subject matter is carrying out the requests the Customer sends to the API. The nature of the processing is automated processing of the content by the models in clause 1.1, in the engine's memory, never on disk or in the logs (clauses 7.1 and 15.10). The purpose is to return to the Customer the response to its request, and nothing else: the content is not used to train any model (clause 7.3). The processing arrangement lasts as long as the Customer's account; the processing of each piece of content, as long as its request and, in the engine's working memory, until it is overwritten (clause 15.10).

15.3. Type of personal data and categories of data subjects. Those the Customer decides to send in its requests. MuninCloud neither chooses them nor knows them in advance.

15.4. Documented instructions. MuninCloud processes the content only on documented instructions from the Customer, which are these terms and each request it sends, including with regard to transfers to a third country or an international organisation (Privacy Policy, clause 5), unless required to do otherwise by Union or Member State law; in that case it will inform the Customer before processing, unless that law prohibits it on important grounds of public interest. MuninCloud will immediately inform the Customer if, in its opinion, an instruction infringes the GDPR or other Union or Member State data protection provisions.

15.5. Confidentiality. MuninCloud ensures that persons authorised to process personal data on the Customer's behalf have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality.

15.6. Security. MuninCloud takes the security measures required by Article 32 GDPR; those it applies to the API are described in clause 7 of the Privacy Policy.

15.7. Sub-processors. The Customer gives its general authorisation for MuninCloud to engage other processors. Today there is one: Hetzner Online GmbH (Germany), which provides the servers on which the API runs, in Falkenstein (Germany; Privacy Policy, clause 6). MuninCloud will inform the Customer of any intended changes concerning the addition or replacement of other processors, before they take place, by email and on this page, as a change to these terms (clause 11), thereby giving the Customer the opportunity to object to such changes: by writing to rgpd@munincloud.com or by closing its account (clause 9.3). Each sub-processor is bound, by contract, by the same data protection obligations that this clause places on MuninCloud, and MuninCloud remains fully liable to the Customer for the performance of its own.

15.8. Data subjects' rights. MuninCloud assists the Customer, taking into account the nature of the processing, so that it can respond to requests for exercising the data subject's rights (Chapter III GDPR). As it does not store the content, it holds no data from it to provide, rectify or erase; if it receives such a request about the content of a request, it forwards it to the Customer.

15.9. Security, breaches and impact assessments. MuninCloud assists the Customer in ensuring compliance with the obligations under Articles 32 to 36 GDPR, taking into account the nature of the processing and the information available to it: it notifies the Customer without undue delay of any personal data breach it becomes aware of, by email to the address of its account, and provides the information on the models and on the place of processing that the Customer needs for an impact assessment.

15.10. When the service ends. The GDPR requires the processor to delete or return the personal data when the service ends. MuninCloud does not store the content of requests or responses: it is not written to disk or to the logs (clause 7.1). While the engine is working, it may remain for a time in its working memory (the prefix cache), isolated per account, without anyone reading it and without any copy, until it is overwritten as the engine is used (Privacy Policy, 2.1). When the service ends there is nothing to return, and whatever remained in that memory is overwritten without being stored anywhere.

15.11. Information and audits. MuninCloud makes available to the Customer all information necessary to demonstrate compliance with this clause, and allows for and contributes to audits, including inspections, conducted by the Customer or another auditor mandated by it. They are requested at rgpd@munincloud.com.

15.12. What is up to the Customer. As controller, the Customer decides which data it sends and for what purpose, and guarantees that it has a legal basis for processing them (Privacy Policy, clause 8).

Updates

23 October 2026 — publication of the terms of the MuninCloud Flexible API.