IntegrationsAtlassian
Atlassian is two deployment stories wearing one brand. Cloud apps go through Forge or Connect and the Marketplace; Data Center apps are installed by an administrator into infrastructure the customer runs. A page that says "we integrate with Jira" has not said anything.
Your AI, MCP server or API
Their workspace and approved access
Their entitled capabilities and version
Validation, health and the next action
Available today
Ready for customer deployments with customer-scoped authorization, validation and lifecycle management.
What a forward deployed engineer does by hand today.
Cloud: a Forge or Connect app, installed by a site administrator, usually via the Marketplace. Data Center: a plugin installed into the customer's own instance, on their upgrade schedule.
The person whose calendar decides your go-live date.
A Jira or Confluence site administrator. In Data Center, whoever owns the servers, which is frequently a different team with a different change process.
Whose identity the product acts as, and where that grant lives.
OAuth 2.0 (3LO) for cloud, with app-scoped tokens for Forge. Data Center authentication is whatever the customer's instance is configured for, which may be SAML, may be LDAP, and is not something the vendor controls.
The repeatable half, turned into software.
The Cloud OAuth 3LO flow, resolving the cloud id that every API call needs and which is only discoverable after authorization, and validation that reads a real project. Data Center is declared and refused at deploy time rather than treated as Cloud, because a wrong assumption there fails inside your customer's own datacentre.
The half that is theirs and should stay theirs.
The site or the instance, project permissions, and the Marketplace approval if their policy requires one.
How capabilities map onto what the platform will let you do.
Scopes for cloud, plus per-project permission schemes that can make a granted scope useless on the project that matters.
What has to execute before anyone is told it works.
Reading a project the customer actually uses, not the sample project, because permission schemes differ per project.
Rotation, expiry, revocation, and who notices first.
Rotating OAuth tokens on cloud. Data Center credentials live in the customer's instance.
What happens to this customer when you ship version four.
Marketplace app versions and per-site installed versions are separate, and Data Center customers upgrade on their own schedule, sometimes years apart.
What actually goes wrong, named rather than generalised.
A scope granted at site level and a project permission scheme that denies it anyway. Cloud and Data Center behaviour differing under identical configuration. Rate limits on large instances.
How you learn it broke without the customer telling you.
Health asks Atlassian which sites the rotating token can still reach and verifies that the installed cloud id remains present. Installation validation separately reads a real Jira project, because a site-level scope can coexist with a project permission scheme that denies every useful project.
Ready for customer deployments with customer-scoped authorization, validation and lifecycle management.
Available for customer deployments, with customer-scoped authorization, validation and lifecycle management.
Connect a source, approve what ships and send your customer an install link. 2 customer environments free. No card required.
