SmartBill + Power Automate: Going HTTP-Only Without a Connector

Scenario: Automating invoice creation from SharePoint to SmartBill

You have:

• A SharePoint list where sales reps log deals (customer, items, prices, VAT, currency).
• SmartBill as the invoicing system for issuing and sending invoices.
• A requirement: when a deal is marked Approved, a SmartBill invoice must be created, and the SmartBill invoice number written back into SharePoint.

There’s no SmartBill connector in Power Automate. The only integration option is SmartBill’s HTTP API.

The rest of this article assumes:

• SmartBill account with API access enabled.
• Power Automate cloud flows.
• You’re comfortable with JSON, HTTP verbs, and basic REST patterns.

We’ll walk through:

1. What you can and can’t do without a connector.
2. How to call SmartBill via HTTP in Power Automate.
3. Licence implications of the HTTP action.
4. Designing flows that respect SmartBill’s 3-calls-per-second limit.

What works with SmartBill in Power Automate without a connector

SmartBill exposes a REST-style API (endpoints, HTTP verbs, JSON payloads). Without a connector, you can still do most integration work:

• Create invoices from upstream data (SharePoint, Dataverse, SQL).
• Retrieve invoice details (for reconciliation or reporting).
• Update local systems with SmartBill IDs, links, or statuses.
• Schedule or event-trigger flows that sync SmartBill activity into other tools.

What you don’t get without a connector:

• No pre-built actions (e.g. “Create SmartBill invoice”) – you build the JSON yourself.
• No built-in connection management UI specific to SmartBill – you handle authentication with generic HTTP capabilities.
• No connector-level throttling or error codes – you must implement your own handling for SmartBill’s limits.

From Power Automate’s perspective, SmartBill is just another HTTP endpoint. The key is configuring the HTTP action correctly and designing flows so they don’t exceed SmartBill’s rate limits.

Premium licence requirement for HTTP actions

The HTTP action used in cloud flows is part of Power Automate’s premium feature set. As of late 2026:

• Using the HTTP action in a cloud flow requires a licence that includes premium capabilities (for example, a standalone Power Automate per-user plan or other plans that explicitly include premium connectors/actions).
• If you only have licences that cover standard connectors (SharePoint, Outlook, Excel) and no premium entitlement, the HTTP action is blocked or requires upgrading.

Important distinctions:

• The HTTP action is available in the cloud flows designer when your environment and user licence allow premium features.
• There is also an HTTP with Azure AD action, which is separate and also premium. Use it only if SmartBill supports Azure AD-based auth (most SmartBill setups use API key or token-based auth instead).

For our scenario, you need:

• A Power Automate environment where premium features are enabled.
• A user (or service account) with a licence that allows running flows with the HTTP action.

If you’re designing a team-wide automation:

• Ensure the account that owns the flow has the premium licence.
• If other users will edit or trigger flows, check whether their licence level affects execution (this can depend on environment-level settings and licensing model). When in doubt, centralize ownership on a licensed service account.

Basic pattern: SharePoint-triggered SmartBill invoice creation via HTTP

Let’s wire the core scenario: when a SharePoint item is approved, call SmartBill’s API to create an invoice.

High-level steps:

1. Trigger: SharePoint — when an item is created or modified.
2. Condition: Only proceed when Status = Approved.
3. Compose SmartBill payload from SharePoint fields.
4. HTTP POST to SmartBill’s invoice endpoint.
5. Parse response to get SmartBill’s invoice ID/number.
6. Update SharePoint with the SmartBill ID.

Example flow structure

In the cloud flow designer:

1. Trigger: When an item is created or modified (SharePoint).
2. Condition: Status equals Approved.
3. Inside the Yes branch:
   • Compose: build the JSON payload for SmartBill.
   • HTTP: POST to SmartBill.
   • Parse JSON: interpret SmartBill’s response.
   • Update item: write SmartBill invoice number back to SharePoint.

Assuming SmartBill expects something like this (structure will depend on SmartBill’s current API docs):

{
  "customer": {
    "name": "Example Customer",
    "vatNumber": "RO12345678",
    "address": "Street 1, City",
    "country": "RO"
  },
  "items": [
    {
      "name": "Service A",
      "quantity": 1,
      "price": 100,
      "vatRate": 19
    }
  ],
  "currency": "RON",
  "issueDate": "2026-10-31"
}

In Power Automate, you’d build that payload dynamically using a Compose action. A robust pattern is to use the Expression editor to construct a JSON object rather than pasting expressions directly into a JSON literal. For example, in the Compose action’s Inputs, use:

json(
  '{
    "customer": {
      "name": "' & triggerOutputs()?['body/CustomerName'] & '",
      "vatNumber": "' & triggerOutputs()?['body/CustomerVAT'] & '",
      "address": "' & triggerOutputs()?['body/CustomerAddress'] & '",
      "country": "' & triggerOutputs()?['body/Country'] & '"
    },
    "items": [
      {
        "name": "' & triggerOutputs()?['body/ItemName'] & '",
        "quantity": ' & string(triggerOutputs()?['body/Quantity']) & ',
        "price": ' & string(triggerOutputs()?['body/UnitPrice']) & ',
        "vatRate": ' & string(triggerOutputs()?['body/VATRate']) & '
      }
    ],
    "currency": "' & triggerOutputs()?['body/Currency'] & '",
    "issueDate": "' & utcNow() & '"
  }'
)

Note: Power Automate does not accept raw JSON with @{...} expressions embedded as shown in conceptual examples; each dynamic value must be added via the Expression editor or dynamic content so that the resulting Compose output is valid JSON. The example above uses the json() function and string concatenation to produce a proper JSON object.

Then configure the HTTP action:

• Method: POST
• URI: SmartBill’s invoice-creation endpoint (from SmartBill API docs).
• Headers:
  • Content-Type: application/json
  • Authorization: value as required by SmartBill (e.g. Bearer <token> or API key header).
• Body: the output of the Compose action.

The response is another JSON document with invoice metadata (ID, number, URL, etc.). Use Parse JSON with a schema derived from a sample SmartBill response, then write the invoice number back into SharePoint.

Managing SmartBill’s 3-calls-per-second limit

SmartBill’s API enforces a 3 calls per second limit. If your flows exceed that, you risk:

• HTTP 429 (Too Many Requests) responses from SmartBill.
• Temporary blocking or throttling of subsequent calls.

In our scenario, this matters when:

• Multiple items are approved in quick succession.
• You run batch flows that loop over many SharePoint items or ERP rows.

How Power Automate behaves under rate limits

Power Automate itself has its own throttling and retry behaviour, but it does not automatically adapt to SmartBill’s external rate limit. If SmartBill returns 429 or similar errors:

• The HTTP action fails for that iteration.
• Depending on your flow configuration, the run might be marked as failed or partially successful.

You need to design the flow to:

• Keep average throughput under 3 requests per second.
• Handle occasional 429 responses gracefully.

Practical patterns to stay under 3 calls/second

For SmartBill, the main tools are:

1. Concurrency control on loops
2. Delays between calls
3. Retry policies tuned for 429

1. Control concurrency on Apply to each

If you process a list of items (e.g. all new deals for the day), Power Automate’s Apply to each can run iterations in parallel. That’s dangerous for an API with a low per-second limit.

For the SmartBill HTTP call:

• In the Apply to each settings, turn off or limit concurrency.
• Set Degree of Parallelism to 1 to serialize calls.

This ensures:

• Only one HTTP call is sent at a time.
• You never exceed 3 calls per second due to parallelism alone.

If you need higher throughput but still respect 3 calls/sec, you can:

• Set concurrency to a small number (e.g. 2 or 3) and add an explicit delay between calls (next section). But keep in mind: with parallelism, you must calculate the worst-case call rate to stay under SmartBill’s limit.

2. Add a small delay between calls

Inside the Apply to each, after the HTTP action, insert a Delay action:

• Delay: PT1S (1 second)

This simple pattern:

• Caps the maximum call rate at roughly 1 per second per loop.
• Keeps you comfortably under SmartBill’s 3-calls-per-second limit even if you later increase concurrency slightly.

Example: processing 60 invoices

• Serialized loop, 1-second delay → ~60 seconds runtime, no throttling.
• Parallel loop with concurrency 3, 1-second delay → ~20 seconds runtime, but you must ensure calls don’t cluster in the same second. For SmartBill’s strict 3/sec limit, conservative designs prefer concurrency 1 plus delay.

3. Handle 429 responses explicitly

If SmartBill returns 429 (Too Many Requests):

• The HTTP action fails by default.
• You can adjust the Retry Policy on the HTTP action.

Typical pattern:

• Set Retry Policy to Exponential.
• Configure a reasonable number of retries and maximum retry interval.

You can also:

• Inspect outputs('HTTP')?['statusCode'] in a Condition.
• If it’s 429, add a longer Delay (e.g. 10–30 seconds), then try again.

Be careful not to create infinite retry loops. Always cap retries and decide what to do with items that repeatedly fail (e.g. log to a failure list and alert someone).

Authentication and secrets: keeping SmartBill keys safe

Without a connector, you manage authentication manually. SmartBill typically uses:

• API keys or tokens passed in headers.

In Power Automate:

• Store SmartBill secrets in a secure location (e.g. Azure Key Vault or environment variables) rather than hard-coding them in flows.
• Use environment variables or connection references where possible to avoid editing flows when keys rotate.

Pattern:

1. Create an environment variable holding the SmartBill API key.
2. In the HTTP action, set the Authorization or custom header to that variable.
3. When the key changes, update the environment variable, not the flow.

This keeps the scenario maintainable for the finance and IT teams as they evolve SmartBill configuration.

Before/after in the scenario

Before:

• Sales reps enter deals in SharePoint.
• Finance staff manually copy data into SmartBill, issue invoices, and paste invoice numbers back into SharePoint.
• End-of-month reconciliation involves messy Excel exports from SmartBill and manual matching.

After (HTTP-only integration):

• When a deal is approved, the flow posts directly to SmartBill’s API.
• SmartBill returns the invoice ID/number; the flow writes it back to SharePoint.
• A separate scheduled flow can pull recent SmartBill invoices and update internal records, again via HTTP.
• Concurrency and delay settings keep calls below 3 per second, avoiding throttling.

No connector, no custom code deployment – just standard Power Automate plus a premium licence and careful handling of SmartBill’s limits.

One practical takeaway

If you’re integrating SmartBill with Power Automate today, treat the HTTP action like a hand-built connector: invest time in clean JSON payloads, strict concurrency control, and delay-based throttling around SmartBill’s 3-calls-per-second limit. That’s what keeps a simple SharePoint-to-SmartBill invoice flow reliable enough for real finance operations.