Forem: Alexey Panteleev

Engineering the Last Mile: How BrightSync Solved the Meeting Intelligence Capability Gap

Alexey Panteleev — Mon, 30 Mar 2026 19:37:13 +0000

The promise of a Capability Platform is simple: developers should focus on their app's unique value, while an infrastructure layer handles the messy business of data synchronization.

For years, that infrastructure has been limited to the "Standard Four": Emails, Calendars, Contacts, and Tasks. But as AI becomes the core of the modern sales stack, a massive capability gap has emerged: Meeting Intelligence.

Here’s how we’re using BrightSync—the engine under the hood of Yoxel—to bridge that gap by pulling native transcripts and summaries directly into your API.

The Problem: The "Bot" Overhead and API Fragmentation

Most devs trying to pull meeting data face two bad choices:

The Bot Route: Building or licensing "meeting bots" that join calls. They are intrusive, fragile, and a nightmare to manage at scale.
The DIY API Route: Writing custom integration logic for Zoom, Microsoft Teams, and Google Meet APIs. Each has different permission scopes, file formats, and storage locations (OneDrive vs. Google Drive).

Expanding the BrightSync Engine

We’ve evolved the BrightSync architecture to treat Meeting Intelligence as a first-class citizen.

BrightSync now has the specialized logic to navigate the backend of Google Workspace and Microsoft 365 to find:

Native Transcripts: Source-truth text without OCR or third-party recording.
Attendance Reports: Precision JSON data on participant dwell time.
AI Summaries: Leveraging the native LLM outputs from the meeting providers themselves.

Solving for "Canonicalization" via White-Glove Push

Data like a "Meeting Summary" doesn't have a RFC standard yet. It’s unstructured and varies by provider. To solve the Capability Problem today, we’ve adopted a hybrid approach:

Extraction: BrightSync handles the heavy lifting of authentication and file discovery.
Transformation: Our team works with you to map these unstructured payloads.
Delivery: We push the data directly to your platform's API endpoint.

Instead of you building a listener for every cloud storage change or meeting end-event, BrightSync acts as the Revenue Data Infrastructure that delivers the "meat" of the meeting directly to your database.

Why this matters for Devs

By offloading the "hunting and gathering" of meeting files to BrightSync, you eliminate months of integration debt.

No-Bot Architecture: Cleaner UX and lower latency.
Unified Auth: Use the same BrightSync/Aurinko tokens you use for Calendar/Email sync.
Custom Schema Support: We don't force you into a rigid model; we push to your API.

The "Standard Four" are no longer enough. It's time to make Meeting Intelligence a native capability of your stack.

The Hidden Risk of Using Shared OAuth Apps (Nylas, Unipile, etc.)

Alexey Panteleev — Tue, 24 Mar 2026 15:54:41 +0000

If you’re building a product that integrates with Gmail or other Google services, you’ve probably run into a major hurdle:

Google OAuth verification for restricted scopes (like Gmail) is painful, expensive, and slow.

Platforms like Nylas and Unipile offer an appealing shortcut:

No need to create your own Google Cloud project
No need to pass OAuth verification
No need to undergo a security assessment

You just plug into their shared, already-verified app and ship faster.

It’s a compelling value proposition.

But there’s a tradeoff that’s often under-discussed — and it’s a big one.

The Convenience: Why Shared Apps Exist

The shared app model solves a real problem.

Google requires:

OAuth verification for sensitive/restricted scopes
Annual third-party security audits (for Gmail, etc.)
Clear privacy policies and strict compliance

For most startups, that’s:

expensive
time-consuming
sometimes a blocker to launching at all

So platforms like Nylas step in and say:

“Use our verified app. We’ve already done the hard part.”

And it works.

The Risk: You Don’t Control Your Own Access

When you use a shared app, you are not the app in Google’s eyes.

Instead:

The OAuth client = Nylas (or Unipile)
The verified entity = Nylas
The security audit = Nylas

Your product is downstream.

That leads to a critical dependency:

If Google revokes or suspends that shared app, your integration breaks — instantly.

Not just for you.

For every customer using that platform.

A Single Point of Failure

This creates a structural risk:


Google → Shared OAuth App (Nylas/Unipile) → Your App → Your Users

If something goes wrong at the platform level:

Policy violation
Security incident
Misrepresentation
Abuse by any customer

Google doesn’t block “one bad actor.”

They can:

shut down or restrict the entire OAuth app

Which means:

Your users lose Gmail connectivity
Your core feature may stop working overnight
You have no direct recourse with Google

You’re not the verified party — the platform is.

You Inherit Everyone Else’s Risk

This is the part many developers underestimate.

With a shared app:

You’re not just trusting Nylas or Unipile
You’re trusting every other developer using that same app

Because:

Google sees one app
One set of scopes
One policy surface

If another customer:

misuses email data
violates Google’s API policy
triggers enforcement

👉 You can get caught in the blast radius.

Limited Visibility, Limited Control

There’s another subtle issue:

Google’s verification system is designed to ensure:

the app is legitimate
the app is secure
the app accurately represents its data usage

But with a shared app:

Google verifies the platform
Not your product

So:

Your app is not reviewed
Your data handling is not audited
Your use case is not directly evaluated

From Google’s perspective:

The platform is the app accessing Gmail data.

My Take: This Is a Half Measure

Here’s the uncomfortable truth.

If Google’s goal is to:

protect user email data and ensure it is handled securely

Then the shared app model is, at best, a half measure.

Because in reality:

Email data does not stay within the platform
It flows into your application
It gets stored, processed, and used by your systems

Yet:

Your infrastructure is not audited by Google
Your security practices are not verified by Google
Your actual use of the data is largely invisible to Google

So the system ends up enforcing:

✅ Security and compliance at the platform level

❌ But not at the end application level, where data actually lives

Why Google Still Allows It

To be fair, there’s a reason this model exists.

If Google required every app to:

pass verification
undergo security audits

…it would kill a huge portion of the developer ecosystem.

So instead, Google made a tradeoff:

Trust a smaller number of intermediaries
Hold them accountable
Accept reduced visibility downstream

When Using a Shared App Makes Sense

Despite the risks, shared apps can still be the right choice if:

You’re early-stage and need speed
You’re validating a product idea
Email integration is not mission-critical (yet)
You’re okay with platform dependency

When You Should Be Careful

You should think twice if:

Email is core to your product
You need long-term stability
You’re building enterprise-facing features
You want full control over compliance and security

In those cases, relying entirely on a shared app can become a liability.

A More Durable Path (Without Shared Apps)

If you’re building a product where email access is core, the more durable approach is to own the integration from day one.

That typically means:

Creating your own Google Cloud project
Implementing OAuth directly
Going through Google’s verification process
Completing the required security assessment (for restricted scopes)

Yes — it’s slower and more expensive upfront.

But in return, you get:

full control over your integration
a direct relationship with Google
no dependency on a third-party platform’s approval status
isolation from risks caused by other apps

A Practical Middle Ground: Allow-Listing

If full verification isn’t immediately feasible, you can consider an app allow-listing approach:

Restrict your app to specific Google Workspace domains or test users
Work with Google to approve limited usage without full public rollout
Use this phase to validate your product and prepare for full verification

This lets you:

stay compliant with Google’s policies
avoid the shared-app dependency entirely
incrementally move toward full production readiness

Final Thought

Building your own OAuth integration is harder.

But it aligns the system the way Google’s model was originally designed:

the entity that builds the product is the one that is verified, audited, and accountable.

If you’re serious about handling user email data long-term, that alignment matters — not just for compliance, but for control, reliability, and trust.

See my earlier post and GIMAP option Gmail Access Evolution: From GIMAP to OAuth Restrictions to IMAP again

MS Dynamics Web API Quirks: The Strange Case of Polymorphic Fields

Alexey Panteleev — Sun, 15 Mar 2026 22:43:30 +0000

If you’ve ever integrated with Microsoft Dynamics 365 / Dataverse, you probably noticed something odd almost immediately. You read a record and see fields like this:

{
  "_ownerid_value": "151F639c-1c73-eb11-b1ab-000d3a253b40"
}

But when creating or updating records, the API suddenly expects something like:

{
  "ownerid@odata.bind": "/systemusers(151F639c-1c73-eb11-b1ab-000d3a253b40)"
}

And if the field is polymorphic, sometimes the property name changes again:

{
  "parentcustomerid_account@odata.bind": "/accounts(ce9eaaef-f718-ed11-b83e-00224837179f)"
}

Welcome to one of the most confusing parts of the Dynamics Web API: lookup and polymorphic fields. Let’s unpack what’s going on.

What are polymorphic fields in Dynamics?

Some relationships in Dynamics can point to multiple entity types.

Example metadata:

{
  "LogicalName": "ownerid",
  "Targets": [
    "systemuser",
    "team"
  ]
}

This means a record owner can be:

A system user
A team

Other examples of polymorphic lookups include:

Field	Possible Targets
`ownerid`	`systemuser`, `team`
`customerid`	`account`, `contact`
`regardingobjectid`	Many entities

Conceptually this is powerful: the schema allows one relationship field to point to multiple tables. But it introduces some interesting API behavior.

The 3 different names for the same field

One of the first confusing things developers notice is that the same lookup field has different names depending on context.

1️⃣ Metadata name

In the schema or metadata: ownerid

2️⃣ Reading records

When retrieving records, the field becomes: _<field>_value.
Example response:

{
  "_ownerid_value": "151F639c-1c73-eb11-b1ab-000d3a253b40"
}

Additional annotations often appear:

{
  "_ownerid_value": "GUID",
  "_ownerid_value@Microsoft.Dynamics.CRM.lookuplogicalname": "systemuser",
  "_ownerid_value@OData.Community.Display.V1.FormattedValue": "John Smith"
}

So when reading data, you need to interpret three separate pieces of information to understand the relationship.

3️⃣ Writing records

When creating or updating records, Dynamics expects OData binding: <lookup>@odata.bind.

Example:

{
  "ownerid@odata.bind": "/systemusers(151F639c-1c73-eb11-b1ab-000d3a253b40)"
}

Pattern:
<lookup>@odata.bind : "/<entityset>(GUID)"
(Where the entity set name is pluralized).

When polymorphic fields get even stranger

Some polymorphic lookups require the entity name to be embedded in the property.

Examples:

"parentcustomerid_account@odata.bind": "/accounts(GUID)"
"parentcustomerid_contact@odata.bind": "/contacts(GUID)"

Pattern:
<lookup>_<entity>@odata.bind

This is where things become particularly confusing because the property name itself changes depending on the target entity.

The special case: `ownerid`

ownerid behaves slightly differently. Unlike other polymorphic fields, you do not include the entity suffix. Both of these work:

"ownerid@odata.bind": "/systemusers(GUID)"
"ownerid@odata.bind": "/teams(GUID)"

The entity type is inferred from the entity set in the URL, not the property name. This exception is one of the reasons developers often find Dynamics integrations unpredictable.

What developers say about this

If you search StackOverflow or Dynamics forums, you'll see the same questions again and again:

Why does the API return _ownerid_value instead of ownerid?
Why do some lookups require @odata.bind while others require field_entity@odata.bind?
Why does the field name change depending on whether you're reading or writing?

A common pattern in discussions is developers discovering the correct format through trial and error rather than documentation. The API reflects years of evolving platform architecture, and that complexity leaks into the integration layer.

Why this matters for integrations

If you're building integrations with Dynamics — especially sync engines, SaaS connectors, or data pipelines — this complexity adds up quickly. Your integration code ends up handling:

Polymorphic lookup detection
Entity-type resolution
OData binding formats
Multiple naming conventions
Response annotations

A simpler approach: Canonical CRM models

At Aurinko, we’re currently finalizing MS Dynamics support in our canonical CRM API. One of the main goals is to remove these platform-specific quirks from the developer experience.

Instead of dealing with _ownerid_value or ownerid@odata.bind, developers simply work with:

owner.id
owner.type
owner.name

Aurinko handles the heavy lifting behind the scenes:

Polymorphic lookup resolution
Entity type detection
OData binding logic
Dynamics naming conventions
Schema inconsistencies

The result is a clean, consistent model across CRM platforms, so your integration code doesn't need to understand the quirks of each individual API.

Final thoughts

Microsoft Dynamics is an incredibly capable platform, but its API reflects the complexity of a large enterprise system.

Context	Field Name
Metadata	`ownerid`
Read	`_ownerid_value`
Write	`ownerid@odata.bind`

Add polymorphic suffix rules and annotations, and it's easy to see why developers often spend time decoding the API instead of building features. Our goal with Aurinko is simple: make CRM integrations feel predictable again.

And sometimes that starts by hiding _ownerid_value forever.

Why Unified APIs Aren't Enough: The "Sync Logic" Trap 🕳️

Alexey Panteleev — Sun, 15 Mar 2026 14:36:37 +0000

If you’ve ever built a CRM, an ATS, or a Project Management tool, you know the drill. A customer asks for "Google and Outlook integration." You look at the APIs, realize they are wildly different, and decide to use a Unified API.

It feels like a win. You have one schema for contacts, one for calendar events, and one for emails. You think you’re 90% done.

You aren’t. You’re actually about 10% done.

The hard truth that many developers learn the hard way is that connectivity is not synchronization. While a unified API handles the "handshake" and the data mapping, it leaves the most expensive, bug-prone part of the project—the Sync Logic—entirely in your lap.

1. The "Lowest Common Denominator" Problem

Unified APIs are great at normalizing data, but they often strip away the "behavioral" intelligence of the underlying provider.

Take Calendar Recurrence. Google and Outlook handle recurring events (and their exceptions) differently. A unified API might give you a standard JSON object for an event, but it won't tell you how to calculate the next three years of "the third Thursday of the month, unless it's a holiday."

If you want those events to show up correctly in your app, you have to write the recurrence engine.

2. The Multi-User Deduplication Nightmare

Imagine three people in your company are on the same meeting invite. If your app syncs all three of their mailboxes, a standard unified API will simply hand you three "new" events.

Without a sophisticated Sync Engine, your database will end up with three separate records for the same meeting. Building the logic to recognize these as a single "Group Event" across multiple accounts is a massive undertaking that involves:

Global Thread ID tracking
Participant matching
Conflict resolution (who’s version of the notes is the "source of truth"?)

3. The "Polling vs. Webhooks" Swamp

Not every provider supports webhooks for every object. This forces you to build a State Management System. You have to:

Store "Sync Tokens" or "Last-Modified" timestamps for every user.
Build a background worker to poll for changes.
Handle delta-calculation (comparing the new data to your DB to see what actually changed).

This isn't just a few lines of code; it's a distributed systems challenge that requires robust queuing (like Redis/Sidekiq/RabbitMQ) and error handling.

4. Conflict Resolution (The "Race Condition" from Hell)

What happens when a user updates a contact's phone number in your app at the exact same time they update it in HubSpot?

Standard unified APIs will just push the update. If you haven't built a Conflict Resolution Engine, you’ll end up in a "Sync Loop" where two systems keep overwriting each other forever, or worse, you lose customer data.

Focus on the Product, Not the Plumbing

As we discussed in our recent deep dive on The Hidden Cost of Internal Integrations, building this logic internally is a "million-dollar distraction."

When you use a platform like Aurinko, you aren't just getting a unified API. You’re getting pre-built sync logic.

Hardened Recurrence: We handle the "monster" of calendar exceptions.
Deduplication: We merge multi-user signals into single entities.
Managed State: We handle the polling, the deltas, and the webhooks.

The Bottom Line

If you are spending more time writing if (provider == 'outlook') { ... } blocks and managing background sync workers than you are building your core product features, you’ve fallen into the Sync Logic trap.

Unification is the start. Sync is the finish line.

*What’s been your biggest headache when syncing third-party data? *

Why Your Unified API is Failing Your Frontend (And Why Metadata is the Cure)

Alexey Panteleev — Sun, 15 Mar 2026 14:28:45 +0000

If you’ve ever built a SaaS integration, you’ve probably reached for a Unified API. The promise is seductive: write one integration for "CRM Contacts" and suddenly you support Salesforce, HubSpot, and Pipedrive.

But as soon as you try to build a Dynamic UI—like a sidebar widget or a custom mapping screen—the "Unified" dream turns into a "Least Common Denominator" nightmare.

There is a massive gap between Data Sync and Dynamic Presentation. To bridge it, we need to stop talking just about data and start talking about Unified Metadata APIs.

1. The "Data Sync" Trap

Most Unified APIs today are built for the Backend-to-Backend use case. They are essentially ETL (Extract, Transform, Load) tools with a REST wrapper. Their goal is to move a Contact object from Salesforce to your database.

The Problem: To make this work, the provider has to "flatten" the data. If Salesforce has a custom picklist for Lead_Quality__c and HubSpot doesn't, the Unified API often strips it out or buries it in a generic raw_data blob.

For a background sync, that’s fine. For a developer trying to draw a form dynamically, it's a dealbreaker.

2. The Dynamic UI Challenge: "Drawing" the Form

In dev forums, we often talk about Server-Driven UI (SDUI) or Schema-Driven Development. This is where the frontend doesn't "know" what the fields are until runtime.

Imagine you're building an integration widget. Your customer says, "I need our custom 'Contract Value' currency field to show up in your app."

With a standard Unified API: You have to manually code a mapping for every customer's custom fields. You're back to square one, hardcoding specialized logic for every "unified" provider.
With a Unified Metadata API: Your frontend asks: "What does the 'Deal' object look like for this specific user right now?" The API responds with the schema, not just the data.

3. Unified API vs. Unified Metadata API

The distinction is subtle but critical for "Embedded" integrations:

Feature	Unified API (Data Sync)	Unified Metadata API (Presentation)
Primary Goal	Moving records between DBs	Generating Dynamic UI at runtime
The "What"	The Data (e.g., "John Doe")	The Schema (e.g., "FirstName is a String, max 50")
UI Strategy	Hard-coded forms / Manual mapping	Dynamic Presentation (Auto-gen forms)
Handling Custom Fields	Usually ignored or "flattened"	First-class citizens; described via metadata

4. Why "Headless Integration" Needs Metadata

We’ve embraced Headless CMS because it decouples content from presentation. We need the same for integrations.

A Unified Metadata API acts as the "Headless" layer for SaaS. Instead of just giving you the data, it provides the "Rules of Engagement" for that data. It tells your UI:

"This field is a Picklist."
"These are the allowed options for this specific user."
"This field is Read-Only based on their permissions."

This allows you to build a single React or Vue component that can draw a valid Salesforce form or a HubSpot form without you ever knowing the underlying API quirks. You build the logic once; the metadata handles the variety.

The Conclusion: Stop Syncing, Start Describing

If your goal is just to populate a dashboard with aggregate data, a standard Unified API is great.

But if you are building In-App Integrations where users interact with 3rd-party data in real-time, you don't just need a data pipe. You need a Unified Metadata API.

It’s the difference between seeing a photo of a room (Data) and having the blueprints to rebuild it (Metadata).

What’s your experience? Have you hit the "Least Common Denominator" wall with integration providers?

Here is a link to my earlier blog post The Case for Unified Metadata APIs

The ERP Developer Tax: Why Integrating with NetSuite, Acumatica, and Fishbowl is an "Onboarding Nightmare"

Alexey Panteleev — Sat, 14 Mar 2026 14:36:32 +0000

Ask any developer who has built integrations for Stripe, GitHub, Shopify, or Salesforce, and they’ll tell you it’s usually a great experience. You register your app once in a central developer portal, you're issued a single Client ID and Shared Secret, and you are done. Your app is recognized throughout that platform's entire ecosystem. When a new customer signs up, you just send them through a streamlined OAuth consent flow. It’s clean, it’s modern, and it works.

Now, ask any developer who has had the "pleasure" of integrating with major ERP players like NetSuite, Acumatica, or Fishbowl. Be prepared to see a pained expression. Welcome to the parallel dimension of decentralized, instance-specific onboarding, otherwise known as the "ERP Developer Tax."

This single issue represents the biggest frustration for developers entering the ERP ecosystem, creating an archaic workflow that kills onboarding conversion and forces SaaS companies to maintain massive, sensitive databases of client secrets.

Let's break down exactly what this situation looks like, why it exists, and how we are trying to fix it at Aurinko.

The Pain: One Client ID, Infinite Problems

The fundamental problem isn't technical capability; it's a difference in ecosystem philosophy. The ERP world, unlike modern PaaS, largely functions on a model of decentralized, local sovereignty.

When you develop for Acumatica, NetSuite, or Fishbowl, there is no central "Developer Center" where you can register your integration once. Instead, your application is a stranger to every single installation.

You can't build a "one-click" setup. There is no "Connect to NetSuite" button that takes the user to a global auth screen.
Registration is manual and per-instance. For every new customer that signs up for your integration, the "Onboarding Guide" becomes required reading.

The "Rite of Passage" on Major Platforms

NetSuite: The user (typically an Admin, as standard users lack permission) must manually go to the "Integration Records" screen, create a new record for your app, copy the Consumer Key and Secret that are uniquely generated, and paste them back into your onboarding flow. You now have a database with one NetSuite secret. When your next customer signs up, you get to do it again.
Acumatica: It’s a similar story. The admin navigates to the "Connected Applications" (SM303010) screen. There, they register your app by its name, and the system generates a unique Client ID and Shared Secret specific only to that Acumatica site and its tenants.
Fishbowl: The traditional desktop product (Fishbowl Advanced) is even more extreme. Authentication is session-token-based. Your app sends an initial introduction request, which is immediately blocked by the server. A human admin must then literally log into the physical server, open the "Integrated Apps" tab, and click an "Approve" button to allow your specific appID access.

This means if you have 500 customers using your NetSuite integration, you are managing 500 unique sets of NetSuite credentials. This decentralized mess is an operational nightmare for your support team, an absolute conversion-killer for your onboarding flow, and a major security risk for your organization.

The Consensus: We’re All Complaining About This

If this sounds incredibly frustrating, that's because it is. You don't have to look far in developer communities to see the fallout. Forums for Acumatica, the NetSuite sub-reddit, and various developer Discords are full of posts lamenting the onboarding friction.

The #1 complaint is the total lack of onboarding control. Instead of providing a modern web experience, developers are reduced to sending clients complex 10-page setup PDFs ("Guide to Getting Started with our NetSuite Integration").

The common refrains include:

"Why can't I just register my app and have clients authorize it like they do with QuickBooks Online?"
"My client's IT admin has been trying to set up the OAuth for three days. How can I possibly support this?"
"I’m literally paying the NetSuite SDN fee just to try and automate this local setup, and it’s still ridiculous."

The "Why": Sovereignty and Legacy

So, if this is universally hated, why don't platforms like Acumatica or NetSuite just modernize and move to a global model? The reasons are rooted in the unique requirements of the ERP market:

Security Sovereignty and Liability: ERP data is the single most sensitive asset a business owns. Moving from local registration to a global registration means the ERP vendor would have to operate a centralized, trusted authority that acts as the source of truth for all client authorizations. The current decentralized model allows the ERP to say: "The integration handshake happened completely within your own instance; if something goes wrong, you are the one who explicitly allowed it." It’s an effective way to shift liability directly to the customer's CFO.
The Private Cloud/On-Prem Challenge: Modern SaaS like Salesforce lives entirely in the public cloud. However, major ERP components can be installed "on-premises" (Fishbowl Advanced) or in "private cloud" environments (Acumatica, NetSuite's private offerings). For these systems, a global OAuth model would require every single instance, including those behind deep corporate firewalls, to "phone home" to a central authority to validate a global Client ID and Secret every time a request is made. Many enterprise customers (healthcare, finance, defense) simply will not allow this level of traffic.

Can We Make the Management Less Painful?

Are you currently dealing with the nightmare of managing 100+ unique Client IDs and Secrets across a fragmented customer base?

At Aurinko, we’re trying to simplify this reality. We realize that as long as ERPs prioritize local sovereignty, the manual setup steps for ERP admins are here to stay. However, we believe the management of those connections shouldn't fall entirely on your shoulders.

We are working on ways to unify these decentralized tenant OAuth registrations and streamline the resulting auth flows. Our goal isn't to change how the ERPs work, but to change how much of that complexity you have to touch.

If you’re feeling the weight of the "ERP Developer Tax," we’d love to hear how you’re handling it today—let’s talk and see if we can make the process a little less manual for everyone.

Dealing with NetSuite's "Chatty" REST API? You Need a Virtual Schema.

Alexey Panteleev — Sat, 14 Mar 2026 13:59:48 +0000

If you are moving from NetSuite’s legacy SOAP SuiteTalk to their modern REST API, you might expect a standard "Stripe-like" experience. Instead, you're greeted by a hyper-verbose HATEOAS architecture that requires constant back-and-forth communication just to retrieve basic data.

As highlighted in Aurinko's deep dive into NetSuite, there are several "quirks" that make direct integration a headache. Here is how the Virtual Schema approach can save your development cycle.

1. The "1+N" Request Trap 🪤

NetSuite follows the HATEOAS (Hypermedia as the Engine of Application State) pattern strictly. This means that when you request a collection of records—say, a list of 100 Contacts—NetSuite doesn't actually give you the contact details.

It gives you a list of IDs and URIs.

The Workflow:

Request 1: Get the list of IDs.
Requests 2-101: Make a separate GET request for every single ID to actually see the names, emails, and phone numbers.

For developers, this is a performance nightmare. You’re forced to manage massive concurrency and throttled limits just to display a simple table of data.

2. The "Green" API Gap 🧪

NetSuite’s REST API is still evolving. While it aims for full coverage, many essential business objects are missing or incomplete.

The Beta Wall: Major objects like Opportunities are often restricted to the Beta version of the API.
Partial Updates: Even in Beta, you might be able to read an object but find yourself unable to create or update its sub-components (like line items).

This forces developers to maintain a "hybrid" integration—part production REST, part Beta REST, and sometimes part legacy SOAP—just to get the job done.

3. Metadata Frankenstein 🧟‍♂️

In a perfect world, you’d pull an OpenAPI spec and start coding. In NetSuite, the metadata is rarely 100% accurate.

Split Truth: You often have to merge data from the OpenAPI spec and the internal object properties to get a complete picture of the fields.
Ghost Fields: It’s common to find fields in the documentation that don't exist in the actual response, or vice versa.

4. Silence on Success (The 204 Problem) 🔇

When you create or update a record, NetSuite returns a 204 No Content status. While it provides the new record's ID in the header, it doesn't return the object.
If your app needs to know the system-calculated values (like dateCreated, totalAmount, or internalID), you have to make yet another GET request immediately after your POST.

There is a better way: The Dynamic API Approach 🛡️

Would you consider a simpler alternative? Instead of writing custom logic to handle 1+N requests, metadata merging, and 204-responses, you can use the Aurinko Dynamic API.

How it works:

Define a Virtual Model: Create a clean Contact or SalesOrder object in the Aurinko portal.
Let the Gateway Handle the Chatter: Aurinko acts as a smart proxy. When you ask for a collection, Aurinko performs the 1+N fetches behind the scenes and returns a single, flattened JSON array to your app.
Unified Metadata: Aurinko reconciles the spec inaccuracies for you, providing a single source of truth for your mappings.

Why Virtualization Wins for NetSuite:

Flat Payloads: No more chasing HATEOAS links. You get exactly the data you asked for in one shot.
Stateless Transition: Aurinko handles the "Silence on Success" by fetching the created object and returning it to your app in a single transaction.

Conclusion

NetSuite is a powerful engine, but its REST API reflects its internal complexity. If you're tired of the "chatter," the Beta-state objects, and the metadata guessing games, it’s time to look at a Virtual API layer.

Stop building on top of ERP quirks. Start building on a clean, virtualized model.

netsuite #api #erp #architecture #backend #webdev #aurinko

Why Acumatica’s API Feels Like RPA in a REST Suit (And How to Fix It)

Alexey Panteleev — Sat, 14 Mar 2026 13:39:54 +0000

If you’ve ever integrated with Acumatica’s Contract-Based REST API, you’ve likely had a "Wait, what?" moment the first time you looked at the JSON.

Why is every field an object? Why am I managing cookies in 2026?

Let's dive into the "Value Wrapper Tax," the "Stateful REST" irony, and how a canonical gateway can save your sanity.

1. The "Value Wrapper" Tax 💸

In a standard API, a Sales Order might look like this:

{
  "CustomerID": "C01",
  "OrderType": "SO"
}

In Acumatica, you get this:

{
  "CustomerID": {"value": "C01"},
  "OrderType": {"value": "SO"}
}

Why does this exist?

Acumatica’s API isn't a direct line to a database; it’s a mapping of the UI Screen. In an ERP, "Null" is a dangerous word. The wrapper allows the system to distinguish between:

Omitted: "Don't touch this field."
Value provided: "Change this to X."
Null Value: "Explicitly clear this field."

The Problem: For developers, this adds massive boilerplate. Every mapping requires an extra .value accessor, doubling the complexity of your transformation logic.

2. The OAuth2 Illusion 🍪

Acumatica supports OAuth2. Great! Stateless at last, right?

Wrong.

Even with a Bearer token, the underlying architecture is stateful. When you hit the API, it initializes a session and hands you an ASP.NET_SessionId cookie.

If your middleware doesn't "capture" that cookie and send it back, every subsequent request creates a brand new session.

The Result: You hit your license’s API Login Limit in seconds.
The Fix: You end up writing a "Cookie Jar" manager just to perform basic CRUD operations.

3. There is a better way: The Canonical Shortcut 🛡️

What if you could stop writing "Acumatica-logic" and start writing "Product-logic"?

Instead of fighting the wrappers and the session cookies, you can use a Canonical Model via a gateway like Aurinko's Dynamic API.

The Workflow:

Your App talks to the Aurinko Dynamic Gateway using a standard, stateless REST call.
Aurinko maps the request to a Canonical SalesOrder model.
The Gateway handles the "dirty work":
Flattening the {"value": ...} wrappers.
Managing the stateful session cookies and logouts.
Translating the screen-based schema into a predictable data object.

Implementing this in SyncHub

In our YoxelSync SyncHub for Salesforce, we’ve found that using this gateway approach allows us to build sync recipes that are actually readable. Instead of a mess of nested JSON references, the recipe looks like a clean field-to-field mapping.

Before (Direct):
Target.Customer = Source.CustomerID.value

After (Canonical):
Target.Customer = Source.CustomerId

It seems like a small change, but when you're mapping 50+ fields across multiple ERPs (Acumatica, NetSuite, FishBowl), the reduction in cognitive load is massive.

Conclusion

Acumatica is a powerhouse ERP, but its API reflects its UI-first philosophy. If you're tired of the "Wrapper Tax" and the "Cookie Dance," it might be time to look at a gateway layer.

acumatica #api #erp #integration #javascript #webdev #aurinko

The Missing Layer in the SaaS Stack: Capability Platforms

Alexey Panteleev — Tue, 10 Mar 2026 22:27:01 +0000

If you look across many SaaS products, you’ll notice something interesting.

Different products often end up building the same infrastructure features:

scheduling
email logging
calendar sync
contact sync
activity timelines

These features appear in many types of software:

CRMs

ATS platforms

customer success tools

vertical SaaS products

But in most cases they are not the core value of the product.

They are infrastructure.

And yet many SaaS teams still rebuild them from scratch.

The Repeated Work in SaaS Integrations

Take activity capture as an example.

Many platforms want to automatically log:

emails
meetings
contacts
tasks

To do this they often need to integrate with systems such as:

Gmail
Microsoft Graph / Outlook
Google Calendar
Exchange

Connecting to these APIs is only the beginning.

The real work often includes building systems for:

synchronization
deduplication
contact matching
recurring events
conflict resolution

Even something that appears simple — like syncing meetings — becomes complicated because providers represent events differently and handle edge cases in different ways.

Over time SaaS teams end up maintaining large integration layers just to support these foundational capabilities.

Existing Approaches

There are tools that try to simplify integrations.

Unified APIs

Unified API providers normalize different APIs behind a single interface.

They make it easier to connect to providers like Gmail or Microsoft Graph.

But they typically stop at data access.

The SaaS platform still needs to build:

activity capture systems
scheduling logic
synchronization engines
data reconciliation

Integration Platforms

Automation tools such as Zapier or Workato can move data between systems.

They are powerful integration tools, but they generally operate outside the product, rather than enabling built-in capabilities.

A Different Idea: Capability Platforms

An alternative idea is what I call a Capability Platform.

Instead of integrating APIs to build each feature, a SaaS platform maps its own data model to a canonical capability model.

Once the mapping exists, capabilities can operate on top of that model.

Conceptually the difference looks like this:

Traditional model

SaaS platform
↓
Build feature
↓
Integrate provider APIs

versus

Capability platform

SaaS platform
↓
Map data model
↓
Capabilities become available

The key shift is that integration happens at the data model layer, not the feature layer.

Example: Scheduling

Imagine a SaaS platform that wants to support meeting scheduling.

Instead of building scheduling infrastructure itself, it maps its event model to a canonical event schema.

Provider events
↓
Canonical event model
↓
Scheduling APIs

Once mapped, the platform can enable capabilities such as:

availability queries
meeting booking
attendee management
rescheduling

The scheduling functionality operates on top of the canonical model rather than individual provider APIs.

Booking Into SaaS Calendars

Sometimes the SaaS platform itself is the system of record for meetings.

Examples include:

CRM platforms
vertical SaaS systems
booking systems

In these cases meetings should be booked directly into the platform’s own calendar rather than into Google or Outlook.

A canonical event model allows scheduling capabilities to work regardless of where the underlying calendar lives.

Activity Capture as a Capability

Another common feature is activity capture.

Many SaaS products want to automatically log:

emails
meetings
contact interactions
communication timelines

Systems like Aurinko’s BrightSync already sync mailbox data such as email, calendars, contacts, and tasks with business systems like CRMs or project management tools.

But the broader idea is that these capabilities could operate on top of shared models rather than requiring every SaaS product to build them independently.

Moving Toward This Model

At Aurinko we’re exploring this idea with canonical capability models such as:

Aurinko Events — scheduling and booking
Aurinko Sync (BrightSync) — activity capture and synchronization

Developers map their APIs and data structures to these models.

Once mapped, they gain access to capabilities such as:

scheduling APIs
availability queries
activity capture
communication sync

It is still early, but some customers are already mapping their systems this way.

A Potential New Layer in the SaaS Stack

Many areas of software infrastructure have moved toward shared capability layers.

Payments → Stripe

Authentication → Auth0

Messaging → Twilio

It’s possible that common SaaS capabilities like scheduling, activity capture, and communication sync could follow a similar pattern.

Instead of every product rebuilding them independently.

The Question

These capabilities already exist in many SaaS products today.

They are necessary, but rarely differentiating.

So the question becomes:

Should every SaaS team keep rebuilding them?

Or could there be room for a Capability Platform layer that turns these features into shared infrastructure?

Originally published at

https://www.aurinko.io/blog/the-case-for-a-capability-platform/

Unleash the Power of Gmail Integration for Developers

Alexey Panteleev — Mon, 11 Dec 2023 21:34:24 +0000

Gmail is more than just an email platform. It's a powerful tool for developers to build apps that enhance user experience and streamline workflows.

Here's a quick overview of what you need to know:

Gmail integration: Connect Gmail with other apps to access data, extend functionality, and automate tasks.
Benefits: Increased efficiency, streamlined workflows, enhanced collaboration, improved decision-making, reduced app fatigue, and access to millions of users.
Types of integration:
- Gmail API: Powerful access, requires coding expertise and OAuth approval.
- Google Workspace Add-ons: Seamless integration, limited UI capabilities and server-side development.
- Chrome Extensions: Unconstrained UI, limited scope and security concerns.
Hybrid approach: Combining Add-ons and API for best of both worlds.
Examples: CRM integrations, project management tools, email marketing platforms.
Challenges: Increased complexity, potential compatibility issues, and security concerns.
Aurinko: Backend platform for Add-ons and Workspace apps, simplifying integration process.

Read the full article in the blog post: Unleash the Power of Gmail Integration for Developers

Navigating the Landscape of Tasks APIs and Integration Challenges

Alexey Panteleev — Wed, 29 Nov 2023 16:21:07 +0000

The integration of Tasks APIs from diverse platforms – spanning project management systems, CRM platforms, and email providers – presents both immense opportunities and integration challenges for developers. My recent blog post talks about Tasks APIs offered by various platforms, delving into the benefits they offer for app developers and product teams while navigating the hurdles of integration.

Key Takeaways:

Diverse Tasks APIs: Explore the array of Tasks APIs across project management, CRM, and email provider platforms.

Integration Benefits: Discover the advantages of integrating Tasks APIs for product teams, including streamlined workflows, enhanced user experience, seamless collaboration, and data consolidation.

Integration Challenges: Understand the hurdles faced by developers, including compatibility issues, authentication and security, data synchronization, and user interface consistency.

Overcoming Challenges: Uncover strategies to maximize benefits and overcome integration challenges, such as thorough research and planning, adopting integration frameworks, prioritizing security measures, and continuous monitoring.

Unified Tasks APIs: Delve into the advantages of using a Unified Tasks API for developers and users, including simplified integration, consistent user experience, and task synchronization across platforms.

Conclusion

The integration of Tasks APIs offers immense potential for app developers and product teams. By overcoming integration hurdles and harnessing the power of Unified Tasks APIs, developers can elevate app functionality, enhance user satisfaction, and drive productivity.

Streamlining Task Management: Navigating the Landscape of Tasks APIs and Integration Challenges

Unveiling the Nuances of Creatio API Integration: A Technical Review

Alexey Panteleev — Sun, 26 Nov 2023 16:15:13 +0000

Fellow developers,

We've recently had the opportunity to delve into the intricacies of integrating with Creatio CRM's OData API, and I'm excited to share our insights with you. This article explores the various aspects of Creatio API integration, including authentication, data organization, search capabilities, and more.

Here's a quick overview of what you can expect from this article:

Authentication: Discover the different authentication methods available for Creatio API integration, including Basic, Forms authentication, and OAuth2.
Data Organization: Understand the unique structure of Creatio data and how to navigate its various levels of referencing.
Search and Query Capabilities: Unleash the power of OData's $filter and $search operators to effectively query Creatio data.
Sync/Deltas API: Learn how to utilize the OData API's query capabilities to filter data by ModifiedOn, enabling incremental data updates.

Whether you're a seasoned developer or just starting your journey with Creatio API integration, this article provides valuable insights and practical tips to enhance your integration experience.

Here is our blog post: Unveiling the Nuances of Creatio API Integration: A Technical Review

I hope you find this article informative and helpful. Please feel free to share your thoughts and experiences in the comments below.

Forem: Alexey Panteleev

Engineering the Last Mile: How BrightSync Solved the Meeting Intelligence Capability Gap

The Problem: The "Bot" Overhead and API Fragmentation

Expanding the BrightSync Engine

Solving for "Canonicalization" via White-Glove Push

Why this matters for Devs

The Hidden Risk of Using Shared OAuth Apps (Nylas, Unipile, etc.)

The Convenience: Why Shared Apps Exist

The Risk: You Don’t Control Your Own Access

A Single Point of Failure

You Inherit Everyone Else’s Risk

Limited Visibility, Limited Control

My Take: This Is a Half Measure

Why Google Still Allows It

When Using a Shared App Makes Sense

When You Should Be Careful

A More Durable Path (Without Shared Apps)

A Practical Middle Ground: Allow-Listing

Final Thought

MS Dynamics Web API Quirks: The Strange Case of Polymorphic Fields

What are polymorphic fields in Dynamics?

The 3 different names for the same field

1️⃣ Metadata name

2️⃣ Reading records

3️⃣ Writing records

When polymorphic fields get even stranger

The special case: ownerid

What developers say about this

Why this matters for integrations

A simpler approach: Canonical CRM models

Final thoughts

Why Unified APIs Aren't Enough: The "Sync Logic" Trap 🕳️

1. The "Lowest Common Denominator" Problem

2. The Multi-User Deduplication Nightmare

3. The "Polling vs. Webhooks" Swamp

4. Conflict Resolution (The "Race Condition" from Hell)

Focus on the Product, Not the Plumbing

The Bottom Line

Why Your Unified API is Failing Your Frontend (And Why Metadata is the Cure)

1. The "Data Sync" Trap

2. The Dynamic UI Challenge: "Drawing" the Form

3. Unified API vs. Unified Metadata API

4. Why "Headless Integration" Needs Metadata

The Conclusion: Stop Syncing, Start Describing

The ERP Developer Tax: Why Integrating with NetSuite, Acumatica, and Fishbowl is an "Onboarding Nightmare"

The Pain: One Client ID, Infinite Problems

The "Rite of Passage" on Major Platforms

The Consensus: We’re All Complaining About This

The "Why": Sovereignty and Legacy

Can We Make the Management Less Painful?

Dealing with NetSuite's "Chatty" REST API? You Need a Virtual Schema.

1. The "1+N" Request Trap 🪤

2. The "Green" API Gap 🧪

3. Metadata Frankenstein 🧟‍♂️

4. Silence on Success (The 204 Problem) 🔇

There is a better way: The Dynamic API Approach 🛡️

How it works:

Why Virtualization Wins for NetSuite:

Conclusion

netsuite #api #erp #architecture #backend #webdev #aurinko

Why Acumatica’s API Feels Like RPA in a REST Suit (And How to Fix It)

1. The "Value Wrapper" Tax 💸

Why does this exist?

2. The OAuth2 Illusion 🍪

3. There is a better way: The Canonical Shortcut 🛡️

The Workflow:

Implementing this in SyncHub

Conclusion

acumatica #api #erp #integration #javascript #webdev #aurinko

The Missing Layer in the SaaS Stack: Capability Platforms

The Repeated Work in SaaS Integrations

Existing Approaches

Unified APIs

Integration Platforms

A Different Idea: Capability Platforms

Example: Scheduling

Booking Into SaaS Calendars

Activity Capture as a Capability

Moving Toward This Model

A Potential New Layer in the SaaS Stack

The special case: `ownerid`