Generate and revoke REST v1 API keys to connect your repair shop management software to external systems via the X-API-Key header: sync repairs, create new tickets, and update statuses from third-party tools. The full key is shown only once, at creation time.
Fixh IT's API keys turn your repair center software into an open platform: from Company > API Keys, your company can generate and revoke REST v1 API keys, used in the X-API-Key header to authenticate requests to the /api/v1/company/... endpoint. This isn't a feature for isolated programmers: it's the bridge between your repair shop and the rest of your software ecosystem, from your website to your accounting software, from your CRM to the bot that answers your customers. For security reasons, the full key is shown on screen only once, right after creation: from that point on it is only visible in masked form (the key_prefix), so it must be copied and stored somewhere safe immediately.
Why it matters for a repair center
A smartphone and PC repair shop rarely works with a single tool: there's the main management system, maybe an e-commerce site for spare parts, a chatbot answering customers on WhatsApp or Telegram, accounting software for invoicing, a marketing tool for email campaigns. Without a real integration, all this information stays siloed in each system, forcing staff to enter the same data multiple times, with a real risk of transcription errors and delayed customer communication. REST v1 API keys solve exactly this problem: they let an external system automatically talk to your company's repair data on Fixh IT, reading a ticket's status, creating new repairs from an online form, or updating a ticket when a technician marks a job as completed. For a repair center handling dozens or hundreds of repairs a month, this integration between smartphone and PC repairs and external software can be the difference between a smooth workflow and one full of manual double entry.
In practice
Each generated API key is tied to your company (key_type "company") and lets an external system authenticate against Fixh IT's REST v1 APIs by including the key in the X-API-Key header of every HTTP request. With this key type you can list your company's repairs filtered by shop, status, or search text, read the details of a single repair, create new ones by specifying shop, customer, technician, device, reported damage, delivered accessories and quote, or update an existing repair by changing its status, payment, delivery, or internal notes. Every request is always automatically filtered to the company the key belongs to: an external system can never see or modify another company's data, even by mistake, because the check happens server-side on every single query.
For security reasons, the full key (the actual secret string) is displayed on screen only once, right after creation: from then on the system stores only a hash of the key and shows just its initial prefix (key_prefix) in the list, enough to recognize it but not to reuse it. It's therefore essential to copy the key immediately and paste it into the configuration file of the external system that will use it, before closing the window: if you forget, the only fix is to revoke that key and generate a new one. Each key also shows its last-used date, useful for understanding whether an integration is still active or can safely be disabled because it's no longer in use. If a key is lost, compromised, or no longer needed, you can revoke it at any time from the list: once revoked it stops working immediately, the revocation date is recorded, and any system using it instantly loses access to the APIs, with no need to intervene anywhere else.
Alongside company-type keys, the same technical setup also has a key type reserved for Fixh IT network resellers, used to automatically manage the issuance and control of license codes from their own management software: the two key types are completely separate (different guards, different permissions), and a company key can never be used for reseller-only operations, or vice versa.
Quick guide
- Go to Company > API Keys.
- Create a new API key, giving it a descriptive name that clearly identifies the integration (for example "Spare parts e-commerce site" or "WhatsApp support bot").
- Immediately copy the full key shown on screen: it won't be shown in full again afterwards, only in masked form.
- Paste the key into the external system's configuration file, in the variable meant for the X-API-Key header.
- Configure the external system to send the key in the X-API-Key header on every request to /api/v1/company/repairs and the other available endpoints.
- Test the integration with a sample call, for example reading the repairs list, to verify the response contains the expected data.
- Periodically check each key's last-used date to spot integrations that are no longer active.
- If needed, revoke the key from the list to immediately stop its use, for example when you switch website providers or stop using an external tool.
Real-world use cases
Repair request form on the website. A smartphone repair shop integrates a "request service" form into its website: when a customer fills it in, an external script calls the repair-creation endpoint with the X-API-Key header, automatically generating a new ticket in the system, already assigned to the correct shop and ready to be picked up by a technician, with nobody having to manually copy the data from the site into the system.
Sync with an external accounting system. A multi-shop company uses a separate accounting software for invoicing: a scheduled integration reads, every night via the API key, the repairs marked as paid and delivered in the last 24 hours, and imports them into the accounting system for tax records, avoiding manual double entry.
Automatic customer notifications via bot. A repair center connects a messaging bot to its system: when a technician updates a repair's status from "in progress" to "ready for pickup" via the API, the external bot periodically checks recently updated repairs and automatically sends the customer a message, reducing in-store calls asking about repair status.
Tips and best practices
Create a separate API key for each integration instead of reusing the same key everywhere: this way, if an external system is retired or compromised, you can revoke just that key without reconfiguring every other integration. Give each key a descriptive name that reminds you at a glance what it's for, especially as you accumulate several over time. Periodically check the last-used date to spot "forgotten" keys tied to systems you no longer use, and revoke them: fewer active keys mean a smaller attack surface. Store the full key in a password manager or a protected configuration file, never in a shared document or a chat message.
Common mistakes to avoid
Never share the same API key across multiple different integrations: if you need to disable one in the future, you risk breaking the others too. Don't embed the key directly in a site or app's public source code: it should always live in a separate, unversioned configuration file. Don't expect to recover the full key after closing the creation window the first time: if you forget to copy it, the only path is to revoke it and generate a new one. Finally, don't forget to revoke keys for retired integrations: an active but unused key remains a potential entry point to your repair data.
Frequently asked questions
Can I view the full key again after creating it? No, for security reasons the full key is only shown at creation time; if you lose it you need to revoke it and generate a new one.
What happens if I revoke an API key? The key stops working immediately, the revocation date is recorded, and every request using it is rejected by the system.
Can I create multiple API keys for the same company? Yes, you can generate several keys, for example one per integration or connected external system, and revoke them individually without affecting the others.
What data can I read or write with a company API key? Your company's repairs: you can list them, filter by shop or status, create new ones, and update the status, payment, delivery, and internal notes of existing ones, always automatically scoped to your company.
Are API keys different from the ones resellers use for licenses? Yes, there are two completely separate key types: company keys for repairs and reseller keys for managing license codes, with distinct permissions and scopes.
Do I need technical skills to use API keys? Yes, the integration requires the external system (website, bot, third-party software) to be programmed to send HTTP requests with the X-API-Key header: it's designed for developers or software vendors working with your repair center.
