Introducing the Mria CRM REST API: Build Integrations and Automate CRM Workflows in Jira
Today, we are introducing the Mria CRM REST API, giving customers and partners programmatic access to CRM data and workflows managed inside Jira.
The API currently provides 190 operations across Leads, Contacts, Companies, Deals, Products, Activities, relationships, custom fields, Jira and Confluence links, and sales metrics. Teams can use it to build their own automations, integrations, reporting pipelines, data-quality controls, and applications around Mria CRM.
This release significantly expands what CRM in Jira can support. Mria CRM can now participate in processes that begin before Sales receives a Lead and continue after a Deal moves to Delivery, Finance, Operations, or company-wide reporting. Customer and commercial context remains connected to Jira while the API makes it available to the next process or system that needs it.
The Mria CRM REST API is available now in Early Access. Here is what has been released and what Jira teams can start building with it.
What the Mria CRM REST API Supports
The Mria CRM REST API turns CRM data into something your wider business systems can actively use. New Leads can be created from website forms or partner systems, Deal updates can launch delivery or finance workflows, and live CRM data can feed reporting tools without manual exports or duplicate entry.
It also enables two-way integrations: external systems can retrieve data from Mria CRM, create and update records, connect related entities, and keep information synchronized while Jira remains the central workspace for your teams.
The current OpenAPI specification includes 190 operations under the /v1 path, covering core Mria CRM records, Activities, relationships, custom fields, reference data, and metrics.
Teams can use the Mria CRM REST API to:
- Manage Leads: create, retrieve, update, delete, search, assign, connect them with Contacts and Companies, and convert qualified Leads into Deals.
- Manage Contacts and Companies: create and update customer records, search them using structured filters, manage notes, and retrieve related CRM and Jira context.
- Manage Deals: create, search, update, clone, or close Deals as Won or Lost; manage associated Contacts and Products; and retrieve pipeline and performance metrics.
- Manage Products: create and maintain the Product catalog and retrieve the Leads, Deals, Contacts, and Companies connected with each Product.
- Work with Activities: add and manage notes, tasks, and meetings; retrieve upcoming Activities; and access Lead and Deal timelines.
- Connect CRM records with Jira and Confluence: add, retrieve, and remove links to Jira work items, Jira boards, Jira or Confluence spaces, Confluence pages, and external web resources.
- Use custom CRM data: retrieve custom field definitions and values, update field values, and search records using conditions such as is_empty, equals, contains, and between.
- Retrieve CRM metrics: access Lead conversion, Deal performance, pipeline value, revenue won, win rate, sales-cycle length, and other CRM metrics for reporting and analysis.
This coverage allows teams to work with the same CRM structure and relationships available in Mria CRM while connecting that data with processes outside the app.
5 Ways to Use the Mria CRM REST API With Jira and External Systems
The API’s broad coverage supports much more than basic data exchange. It can connect lead capture, sales, finance, delivery, and reporting workflows around the same CRM data, reducing manual handoffs and keeping customer information consistent across systems.
Here are five practical ways teams can use it.
1. Capture Leads From External Sources Directly in Mria CRM
A Jira-first sales process can still receive demand from many places. A website form, webinar platform, event list, partner portal, or an internal referral workflow can send a new Lead to Mria CRM through the API.
A typical flow could be:
- A prospect submits a form on the company website.
- A backend service calls POST /v1/leads with the Lead name, Contact name, and email.
- The integration updates the Lead with the relevant source, assignee, tags, products, or custom fields.
- The sales team sees the Lead in its normal Mria CRM view inside Jira and continues qualification there.
This removes spreadsheet handoffs, routes new Leads to the right owner, and preserves the Source needed to understand which channels, campaigns, events, or partners generate demand.
The API can also create and link a new Contact or Company during Lead creation, or connect the Lead to existing Contact and Company records. Integration logic can therefore follow the same relationship model as users working in the Mria CRM interface.
2. Turn a Won Deal Into a Connected Delivery Handoff
For service companies and other Jira-centric organizations, closing the Deal is the beginning of delivery. The customer, commercial scope, products, Confluence documentation, and Jira work should remain connected after the handoff.
An integration can combine the Mria CRM REST API with Jira REST APIs to support that transition:
- Find Deals in a Won stage using structured Deal search.
- Retrieve the Deal, Company, Contacts, Products, amount, and relevant custom fields.
- Create the required Jira work item through the Jira API after granting the separate Jira write scopes required by that operation.
- Call POST /v1/deals/{dealId}/jiraLinks to connect the new work item to the original Deal.
- Add relevant Confluence or Jira space links when the delivery documentation is ready.
Sales keeps the original commercial record. Delivery works in Jira. Both teams can move between the Deal and the work created from it without rebuilding customer context in a second system.
This pattern is particularly useful when every Won Deal follows a repeatable onboarding, implementation, assessment, or service-delivery process.
3. Send Deal and Product Data to Finance or Operations
Closing a sale can trigger work outside Jira: preparing an order, opening a billing account, generating a contract, provisioning a service, or updating an ERP.
The API exposes Deals and the Products linked to them, including quantities and commercial values used on the Deal. An integration can retrieve the relevant data after a Deal reaches a closed stage and pass it to the next system in the process.
For example:
- A Won Deal can create a draft order in an ERP.
- Product and quantity data can start a provisioning workflow.
- Company and primary Contact data can open a customer account in a billing platform.
- A finance reference returned by the external system can be stored in a Mria CRM custom field.
The last step matters. A useful integration should preserve traceability in both directions. Someone opening the Deal in Jira should be able to see the external order, account, or contract identifier without asking another team to look it up.
4. Add Mria CRM Metrics to Company-Wide Reporting
Some leadership dashboards combine sales, delivery, support, finance, and product data. Requiring someone to export a CRM spreadsheet before every reporting cycle creates delays and introduces version problems.
Mria CRM provides both record-level access and metric endpoints. Integrations can retrieve Lead conversion and performance metrics as well as Deal metrics such as open Deals, pipeline value, Deals Won, average Deal value, win rate, sales-cycle length, revenue won, and Deals Lost. Performance endpoints can be filtered by date range and assignee.
This allows a team to prototype reporting such as:
- pipeline value beside current delivery capacity;
- revenue won beside implementation progress;
- Lead conversion by period alongside acquisition data;
- sales-cycle length alongside the time required to start delivery;
- Deal Products alongside product demand or service utilization.
For early access testing, start with a read-only reporting use case. It exercises authentication, pagination, filtering, and data modeling without allowing the integration to change CRM records.
5. Automate CRM Data-Quality Checks
The API can also help teams identify CRM records that are incomplete, outdated, or no longer aligned with their sales process.
Structured search can narrow records by Status, Source, Assignee, Company, Product, dates, amounts, probability, Jira links, and custom field values. An integration can combine these filters with CRM Activities and record relationships to run checks such as:
- Which new Leads have no Source or Assignee?
- Which Leads have had no follow-up Activity within the expected period?
- Which qualified Leads are missing a Company or Product required by the team’s qualification process?
- Which open Deals have already passed their expected closing date?
- Which Deals are approaching their closing date without a planned Task or Meeting?
- Which open Deals have not been updated for a defined number of days?
- Which Deals have no Products even though product-level data is required for forecasting or delivery?
- Which high-value Deals are missing an approval, contract status, or another required custom field?
- Which Won Deals have no linked Jira work item for onboarding or delivery?
- Which Won Deals are still missing an order, billing, or provisioning reference expected from a downstream integration?
A scheduled integration could turn these results into a daily or weekly exception report for CRM administrators and record owners. Once the rules have been validated, it could also apply selected corrections, assign unowned Leads, add follow-up Tasks, or update fields with approved default values.
This helps teams maintain CRM quality continuously instead of discovering missing information during reporting, forecasting, or the handoff from Sales to Delivery.
Before You Build With the Mria CRM REST API
A strong API implementation starts with a clear understanding of access, data ownership, workflow behaviour, and expected scale. These considerations apply whether you are building an external integration, internal automation, reporting pipeline, data-quality process, or custom application.
Define Access Ownership and Permissions
Before configuring API access, decide who will authorize and own the API connection, which Mria CRM role that person requires, and whether the planned workflow needs read or write access.
A site administrator enables App REST APIs for Mria CRM. Authentication uses Atlassian OAuth 2.0 (3LO) without static API keys, and every request follows the Mria CRM permissions of the authorizing user. Read and write scopes are controlled separately, while write operations require an active Mria CRM license.
Documenting access ownership from the beginning helps keep dashboards, automations, applications, and integrations within the permissions they actually require.
Define How Data Should Move
Decide what information the workflow will read, create, or update and which system should control each field.
A reporting pipeline may only consume data from Mria CRM. An integration with an ERP or billing platform may exchange data in both directions and therefore requires clear ownership of customer details, Deal values, Products, and external references.
If CRM data is sent outside Atlassian, include the receiving application, logs, queues, and backups in the organization’s data-access and retention review.
Make Write Workflows Consistent
Create and update workflows should produce the same result when a request is retried. This prevents duplicate Leads, Jira work items, ERP orders, Tasks, or other records.
Keep track of the source item being processed and the records created from it. External order numbers, account IDs, or other returned references can be stored in Mria CRM custom fields when the workflow requires traceability between systems.
It is also useful to make partial completion visible. If one step succeeds and another needs to be repeated, the workflow should be able to continue without recreating the records that already exist.
Plan Data Retrieval and Workflow Triggers
List and search operations use pagination, so API clients should process every required page when working with larger datasets.
Validate the workflow with representative record volumes and choose a trigger that matches the process. A website submission can call the API directly, while reporting or data-quality workflows may run on a controlled schedule.
The current OpenAPI specification does not include webhooks, so workflows that need to detect changes within Mria CRM should use planned polling where appropriate.
Keep Early Access Implementations Adaptable
The API contract may evolve during Early Access, and the underlying Atlassian Forge App REST API capability remains in Preview.
Keeping API-specific logic in a separate layer and validating it against the latest OpenAPI specification makes future updates easier to adopt without redesigning the complete workflow.
Apply these practices in proportion to the use case. A read-only dashboard requires a different level of operational control from a two-way enterprise integration, while both benefit from clear ownership, appropriate permissions, and a maintainable implementation.
Implementation Resources
Detailed configuration and technical examples are available in the documentation:
- Mria CRM REST API overview
- Mria CRM REST API setup
- OpenAPI specification and endpoint reference
- Mria CRM REST API example for Node.js
- Mria CRM REST API example for Postman
Remove the Next Manual Handoff From Your Jira CRM Process
Look at what happens immediately before customer data enters Mria CRM and immediately after a sale moves forward. If a website Lead must be copied from a form, a Won Deal must be recreated as Jira delivery work, Finance waits for Product details, or reporting depends on another export, there is already a clear integration opportunity.
The Mria CRM REST API allows teams to connect that step while keeping the customer and commercial record in Jira. Existing customers can use the implementation resources above to configure access and build their first connection. Teams evaluating Mria CRM can start a 30-day trial on the Atlassian Marketplace.
Because the API is in Early Access, we welcome feedback on the entire experience, whether you are building an integration, evaluating the API for a customer project, or exploring what it could support in the future.
We would especially like to hear:
- Which workflows or use cases do you want the API to support?
- Does the current API provide the records, relationships, filters, and operations you need?
- Is the setup, authentication, and documentation clear?
- Are any endpoints, events, bulk operations, examples, or developer tools missing?
- What security, administration, reliability, or scalability requirements matter for your organization?
- What currently makes the API harder to adopt or use?
Share your feedback in the comments below. Tell us what works, what does not, and what you need from the next versions of the Mria CRM REST API.
Was this helpful?
Thanks!
Anton Storozhuk _Mria Labs_
2 comments