Skip to main content
RapidDev - Software Development Agency
flutterflow-integrationsFlutterFlow API Call

SysAid

Connect FlutterFlow to SysAid by creating a FlutterFlow API Group targeting your SysAid REST base URL, logging in via POST /api/v1/login to receive a JSESSIONID session cookie, storing that cookie in App State, and forwarding it as a Cookie header on every subsequent API call — such as POST /sr to create a help-desk ticket. Because SysAid uses session-cookie auth rather than a simple bearer token, each call chain must carry the live cookie or return 401.

What you'll learn

  • How SysAid's session-cookie (JSESSIONID) auth differs from bearer tokens and why it matters for FlutterFlow
  • How to capture and forward the JSESSIONID cookie header across multiple API calls
  • How to create a Service Record (ticket) via POST /sr from a FlutterFlow form
  • Why admin credentials must live in a Firebase Cloud Function proxy, not in the FlutterFlow project
  • How to handle session expiry by triggering a re-login on a 401 response
Book a free consultation
4.9Clutch rating
600+Happy partners
17+Countries served
190+Team members
Intermediate16 min read45 minutesDevOps & ToolsLast updated July 2026RapidDev Engineering Team
TL;DR

Connect FlutterFlow to SysAid by creating a FlutterFlow API Group targeting your SysAid REST base URL, logging in via POST /api/v1/login to receive a JSESSIONID session cookie, storing that cookie in App State, and forwarding it as a Cookie header on every subsequent API call — such as POST /sr to create a help-desk ticket. Because SysAid uses session-cookie auth rather than a simple bearer token, each call chain must carry the live cookie or return 401.

Quick facts about this guide
FactValue
ToolSysAid
CategoryDevOps & Tools
MethodFlutterFlow API Call
DifficultyIntermediate
Time required45 minutes
Last updatedJuly 2026

Build a Mobile Help-Desk Companion with FlutterFlow and SysAid

SysAid is a full ITSM platform — help-desk tickets, service catalogs, asset management — aimed at enterprise IT teams. Its REST API v1 lets you read and write service records programmatically, which opens the door to a lightweight FlutterFlow mobile app where field technicians or employees can submit tickets, check ticket status, or update records without logging into the full SysAid portal.

The catch that makes this tutorial unique is SysAid's authentication model. Unlike most modern APIs that issue a static bearer token, SysAid authenticates via a POST to /api/v1/login. On success, the server returns a JSESSIONID session cookie in the Set-Cookie response header — and every subsequent call must carry that cookie or it returns 401 Unauthorized. FlutterFlow's built-in API Calls do not automatically relay cookies between separate calls the way a browser would, so you must capture the cookie value from the login response, store it in an App State variable, and manually attach it as a Cookie: JSESSIONID={value} header on each follow-up request.

SysAid is quote-based enterprise software with no public free tier; confirm with your IT team that your company's SysAid account has REST API access enabled for a service account. On-premise SysAid deployments add another consideration: the server must be reachable from the public internet (or via a VPN gateway) for a phone on cellular data to reach it.

Integration method

FlutterFlow API Call

FlutterFlow connects to SysAid through its REST API v1 using a two-step flow: a Login call that exchanges credentials for a session cookie (JSESSIONID), followed by subsequent API calls that forward that cookie as a header. Because FlutterFlow API Calls do not automatically persist cookies between calls, you capture the JSESSIONID from the login response and store it in App State for manual forwarding. For production apps with multiple users, a Firebase Cloud Function proxy handles the service-account login and exposes only safe, scoped endpoints to the FlutterFlow client.

Prerequisites

  • A SysAid account with REST API access enabled and a service-account username and password
  • Your SysAid tenant base URL (e.g., https://yourcompany.sysaidit.com/api/v1) or on-premise URL reachable from the internet
  • A FlutterFlow project (any plan) with at least one screen
  • A Firebase project (for the Cloud Function proxy if building a multi-user production app)
  • Basic familiarity with FlutterFlow App State variables and the Action Flow Editor

Step-by-step guide

1

Confirm API access and find your SysAid base URL

Before writing a single API call in FlutterFlow, make sure the SysAid REST API is switched on for your account. Log into SysAid as an administrator and navigate to Settings → General → REST API. You will see a toggle to enable the API and a section to manage API users. Create a dedicated service account (for example, api-service@yourcompany.com) with the minimum permissions needed: for ticket creation, it needs permission to create Service Records; for status reads, it needs permission to view Service Records. Avoid using a personal admin account because the session will be tied to those credentials. Next, identify your base URL. SysAid Cloud tenants use the pattern https://{yourcompany}.sysaidit.com/api/v1. On-premise installations will have the URL your IT team configured, and it must be reachable from a public IP address — if SysAid is behind your company firewall, a phone on cellular data cannot reach it at all. Confirm public reachability by opening that URL in your browser on a mobile network. Note this URL down; it is the base URL you will enter in the FlutterFlow API Group.

Pro tip: Test reachability with your phone on mobile data before building the FlutterFlow integration — firewall issues are the #1 blocker for on-premise SysAid users.

Expected result: You have a SysAid service-account username and password plus a confirmed, publicly reachable base URL.

2

Create the API Group in FlutterFlow and add the Login call

In your FlutterFlow project, click API Calls in the left navigation panel. Click the + Add button and select Create API Group. Give the group a name like SysAid, and enter your base URL (for example https://yourcompany.sysaidit.com/api/v1) in the Base URL field. Leave the Headers section empty for now — SysAid login does not require any headers beyond Content-Type, which FlutterFlow sets automatically when you choose a JSON body. Now add your first call inside this group. Click + Add API Call. Name it Login. Set the method to POST and the endpoint to /login. Switch to the Body tab, choose JSON, and enter the following body structure: { "user_name": "{{ username }}", "password": "{{ password }}" } Go to the Variables tab and add two variables: username (String) and password (String). These will be passed from your FlutterFlow form fields at runtime — never hardcode the credentials in the body. Switch to Response & Test. Enter sample values for username and password and click Test. A successful login returns HTTP 200. The response body may just be {"status":"OK"} or similar. The important part is the Set-Cookie response header — it will look like JSESSIONID=abc123; Path=/; HttpOnly. You need that cookie value; we will capture it in the next step using App State. Note: FlutterFlow does not expose response headers directly in the normal response binding UI. You will need a Custom Action (Dart) to read the cookie from headers — covered in the next step.

api_call_config.json
1{
2 "method": "POST",
3 "endpoint": "/login",
4 "body": {
5 "user_name": "{{ username }}",
6 "password": "{{ password }}"
7 }
8}

Pro tip: Name the API Group clearly (SysAid) and the call specifically (Login) — you will add more calls to this group shortly and naming matters.

Expected result: The FlutterFlow API Group 'SysAid' is created with a Login call. Testing with valid credentials returns HTTP 200.

3

Store the session cookie in App State via a Custom Action

FlutterFlow's built-in response binding can parse JSON body fields, but it cannot natively read response headers like Set-Cookie. To capture the JSESSIONID, you need a small Custom Action that makes the login HTTP request using Dart's http package and reads the response header directly. Go to Custom Code in the left nav → click + Add → select Action. Name it loginAndSaveCookie. In the Dependencies field, add http (the Dart HTTP package is already bundled in Flutter, so no separate version pin is needed). Paste the Dart code below. Set the Action's return type to String (it returns the cookie value). In your App State (left nav → App State → + Add Field), add a field named sysAidCookie of type String with initial value empty. In your login screen's Action Flow Editor (the Submit button), add the loginAndSaveCookie Custom Action, then add an Update App State action to write the returned cookie string into sysAidCookie. After login succeeds, every subsequent API call will read sysAidCookie from App State and attach it as a Cookie header — as shown in the next step. If the action returns an empty string, display an error message to the user and prompt them to retry.

custom_action.dart
1import 'package:http/http.dart' as http;
2import 'dart:convert';
3
4Future<String> loginAndSaveCookie(
5 String username,
6 String password,
7 String baseUrl,
8) async {
9 final uri = Uri.parse('$baseUrl/login');
10 final response = await http.post(
11 uri,
12 headers: {'Content-Type': 'application/json'},
13 body: jsonEncode({'user_name': username, 'password': password}),
14 );
15
16 if (response.statusCode == 200) {
17 final rawCookie = response.headers['set-cookie'] ?? '';
18 // Extract JSESSIONID value from 'JSESSIONID=abc123; Path=/; ...'
19 final match = RegExp(r'JSESSIONID=([^;]+)').firstMatch(rawCookie);
20 return match != null ? match.group(1) ?? '' : '';
21 } else {
22 return ''; // Login failed
23 }
24}

Pro tip: Test this Custom Action on Run mode or a real device — custom actions that use platform packages do not run reliably in the FlutterFlow web Preview tab.

Expected result: After tapping the login button, the App State variable sysAidCookie is populated with the JSESSIONID value (a long alphanumeric string).

4

Add the Create Service Record API call with Cookie forwarding

Now add the ticket-creation call. In the SysAid API Group (API Calls → SysAid), click + Add API Call. Name it CreateServiceRecord. Set method to POST and endpoint to /sr. In the Headers tab, add one header: Key: Cookie Value: JSESSIONID={{ sessionCookie }} Go to the Variables tab and add sessionCookie (String) — this will be bound to the App State sysAidCookie variable at runtime. In the Body tab, choose JSON and set a payload representing the service record fields. At minimum, SysAid Service Records require a title and category. A typical body looks like: { "info": [ { "key": "description", "value": "{{ description }}" }, { "key": "title", "value": "{{ title }}" }, { "key": "urgency", "value": "{{ urgency }}" } ] } Add corresponding variables: description, title, urgency. In the Response & Test tab, paste a sample successful response (SysAid returns a JSON object with the new SR's id and other metadata). Click + Add JSON Path and extract: $.id → newTicketId (String) $.info[0].value → ticketTitle (String) Back in your FlutterFlow form screen, wire the Submit button's Action Flow: 1. Check that App State sysAidCookie is not empty; if empty, run loginAndSaveCookie first. 2. Call the CreateServiceRecord API Call, binding the sessionCookie variable to App State sysAidCookie and the other variables to your text fields. 3. On success, navigate to a confirmation screen showing the returned ticket ID.

api_call_config.json
1{
2 "method": "POST",
3 "endpoint": "/sr",
4 "headers": {
5 "Cookie": "JSESSIONID={{ sessionCookie }}"
6 },
7 "body": {
8 "info": [
9 { "key": "description", "value": "{{ description }}" },
10 { "key": "title", "value": "{{ title }}" },
11 { "key": "urgency", "value": "{{ urgency }}" }
12 ]
13 }
14}

Pro tip: The urgency field in SysAid is typically an integer (1 = urgent, 4 = low) — confirm your SysAid instance's urgency IDs in the admin panel before hardcoding values.

Expected result: The CreateServiceRecord call is configured with a Cookie header using the session variable. Testing with a valid cookie returns HTTP 200 and a JSON body containing the new SR's id.

5

Build the ticket form and confirmation screen

Now build the UI that drives the API calls. In FlutterFlow, add a new screen called Submit Ticket. Use the Widget palette to add a Column containing: - A TextField widget bound to a Page State variable ticketTitle (String) - A TextField widget with maxLines 4 bound to a Page State variable ticketDescription (String) - A DropdownButton bound to a Page State variable ticketUrgency (String), with options: Urgent (value: 1), High (value: 2), Normal (value: 3), Low (value: 4) - An ElevatedButton labeled Submit On the ElevatedButton's Actions panel, open the Action Flow Editor and set up the chain: 1. Conditional Action: check if App State sysAidCookie is empty. If true → call the loginAndSaveCookie Custom Action and Update App State sysAidCookie with the returned value. 2. Backend/API Call: call CreateServiceRecord, mapping sessionCookie to App State sysAidCookie, title to Page State ticketTitle, description to Page State ticketDescription, urgency to Page State ticketUrgency. 3. Navigate: on success (check response code 200), navigate to a Confirmation screen and pass the returned $.id as a parameter. Create a simple Confirmation screen with a large checkmark icon, a Text widget showing Ticket #[id] submitted successfully, and a button to go back to the home screen. If you need to handle session expiry gracefully, add error handling on step 2: if response code is 401, clear App State sysAidCookie, re-run loginAndSaveCookie, then retry CreateServiceRecord once. This prevents the user from seeing a raw 401 error.

Pro tip: Keep form validation simple — require title and description to be non-empty using a Conditional Action before making any API call, to avoid submitting blank tickets to SysAid.

Expected result: Tapping Submit triggers the login-then-create sequence, and the user arrives at a Confirmation screen showing the new SysAid ticket ID.

6

Add a Firebase Cloud Function proxy for production multi-user apps

The setup above works for a personal or internal single-user app, but it has a security limitation: the user's SysAid credentials (or a hardcoded service-account password) travel from the phone to the SysAid server. For any app distributed to multiple employees, the right architecture is a Firebase Cloud Function that holds the service-account credentials server-side, performs the SysAid login, and exposes a scoped endpoint to the FlutterFlow app. In your Firebase project (Firebase Console → Functions → Get started), create an HTTPS Cloud Function. The function accepts the ticket fields from FlutterFlow, authenticates with SysAid using the service-account credentials stored in Firebase environment config, and POSTs the Service Record. It returns only the new ticket ID to the client — not the full SysAid session cookie. In FlutterFlow, replace the direct SysAid API Group with a single API Group pointing at your Cloud Function URL. The FlutterFlow app no longer manages cookies at all — that complexity moves entirely to the proxy. The client sends only the ticket data (and a Firebase Auth token to verify the user), and receives a simple { "ticketId": "SR-1234" } response. This approach is strongly recommended for any app deployed beyond your own device. If you would rather skip the Cloud Function setup and have RapidDev's team handle the integration architecture, book a free scoping call at rapidevelopers.com/contact.

index.js
1// Firebase Cloud Function (Node.js) — index.js
2const functions = require('firebase-functions');
3const axios = require('axios');
4
5const SYSAID_BASE = functions.config().sysaid.base_url;
6const SYSAID_USER = functions.config().sysaid.username;
7const SYSAID_PASS = functions.config().sysaid.password;
8
9exports.createSysAidTicket = functions.https.onRequest(async (req, res) => {
10 res.set('Access-Control-Allow-Origin', '*');
11 if (req.method === 'OPTIONS') { res.status(204).send(''); return; }
12
13 try {
14 // Step 1: login and grab cookie
15 const loginResp = await axios.post(
16 `${SYSAID_BASE}/login`,
17 { user_name: SYSAID_USER, password: SYSAID_PASS },
18 { headers: { 'Content-Type': 'application/json' }, withCredentials: true }
19 );
20 const rawCookie = loginResp.headers['set-cookie']?.[0] ?? '';
21 const match = rawCookie.match(/JSESSIONID=([^;]+)/);
22 const sessionId = match ? match[1] : '';
23 if (!sessionId) { res.status(401).json({ error: 'SysAid login failed' }); return; }
24
25 // Step 2: create service record
26 const srResp = await axios.post(
27 `${SYSAID_BASE}/sr`,
28 { info: [
29 { key: 'title', value: req.body.title },
30 { key: 'description', value: req.body.description },
31 { key: 'urgency', value: req.body.urgency }
32 ]},
33 { headers: { 'Content-Type': 'application/json', Cookie: `JSESSIONID=${sessionId}` } }
34 );
35 res.json({ ticketId: srResp.data.id });
36 } catch (err) {
37 res.status(500).json({ error: err.message });
38 }
39});

Pro tip: Store SysAid credentials with: firebase functions:config:set sysaid.base_url="https://yourcompany.sysaidit.com/api/v1" sysaid.username="api-service@yourcompany.com" sysaid.password="yourpass" — never paste them in the code file.

Expected result: The Cloud Function is deployed and accessible via HTTPS. FlutterFlow calls the proxy URL instead of SysAid directly; tickets are created server-side with no credentials in the client.

Common use cases

Field technician ticket-submission app

IT field technicians carry phones, not laptops. A FlutterFlow app lets them snap a photo, describe the issue, and POST a new Service Record to SysAid — complete with priority, category, and asset details — without needing to access the full web portal. Tickets appear instantly in the SysAid queue for the service desk to action.

FlutterFlow Prompt

Build a mobile form where a technician selects a ticket category, types a description, sets priority (Low/Medium/High), and taps Submit to POST a new SysAid Service Record. Show a success screen with the new ticket ID.

Copy this prompt to try it in FlutterFlow

Employee self-service ticket tracker

Employees want to check whether their IT request has been resolved without emailing the help desk. A FlutterFlow app can call the SysAid API to list the current user's open service records and show their status, last update, and assigned technician — all in a scrollable card list.

FlutterFlow Prompt

Create a ticket-status screen that lists all open Service Records for the logged-in user, showing ticket ID, title, status, and last modified date. Add a pull-to-refresh gesture.

Copy this prompt to try it in FlutterFlow

IT manager incident overview dashboard

IT managers need a real-time snapshot of open critical incidents. A FlutterFlow app queries SysAid for Service Records filtered by high priority and unresolved status, displaying a summary count and a drill-down list with assignee and time open.

FlutterFlow Prompt

Build an IT dashboard screen that shows the count of open P1 tickets, a list of the 10 most recent critical incidents, and the name of the assigned technician for each.

Copy this prompt to try it in FlutterFlow

Troubleshooting

401 Unauthorized on the CreateServiceRecord call even though login succeeded

Cause: The JSESSIONID cookie was not forwarded correctly in the Cookie header, or the session has expired since the last login call.

Solution: Check the Cookie header in the CreateServiceRecord API Call. The value must be exactly JSESSIONID=<cookie_value> — confirm App State sysAidCookie is not empty before the call. Sessions expire after a period of inactivity; handle 401 responses by clearing sysAidCookie, re-logging in, and retrying the request.

The app cannot reach the SysAid server on cellular data (connection timeout / network unreachable)

Cause: On-premise SysAid servers are typically behind a corporate firewall and not reachable from the public internet.

Solution: Test by opening the SysAid URL in your phone browser on cellular (not Wi-Fi). If it fails, the server is firewalled. Options: use a VPN on the device, expose the server through a reverse proxy, or move to SysAid Cloud.

Custom Action loginAndSaveCookie returns an empty string; App State sysAidCookie stays empty

Cause: The Custom Action did not run correctly in FlutterFlow's web Preview mode (known FlutterFlow limitation), or the SysAid login credentials are wrong, or the Set-Cookie header was not present in the response.

Solution: Always test Custom Actions on Run mode or a real device — not the Preview iframe. Verify the credentials are correct by testing the Login call in the FlutterFlow API Calls Test tab. Ensure the response header name is exactly set-cookie (lowercase) when matching in Dart.

SysAid returns 400 Bad Request when creating a Service Record

Cause: The JSON body structure for POST /sr is incorrect — SysAid requires fields under an info[] array with key/value pairs matching the exact field names configured in your SysAid instance.

Solution: Log into SysAid admin panel and check the exact field keys for your service record template. Common fields are title, description, and urgency; custom fields vary by instance. Compare your JSON body in the FlutterFlow API Call Body tab against those keys.

Best practices

  • Never hardcode SysAid service-account credentials in the FlutterFlow project — use a Firebase Cloud Function proxy for any app distributed to more than one person.
  • Create a dedicated SysAid API service account with minimum permissions (create/read Service Records only) rather than using a personal admin account.
  • Handle session expiry gracefully: on a 401 response, clear App State sysAidCookie, re-run loginAndSaveCookie, and retry the failed call once before showing the user an error.
  • Confirm that your SysAid instance is publicly reachable from the internet before building the FlutterFlow integration — test from a phone on cellular, not on the company Wi-Fi.
  • Use Page State variables for form fields (title, description, urgency) and App State only for the session cookie, keeping the data model clean and scoped correctly.
  • Keep the ticket form simple — title, description, and priority are enough to open a valid Service Record in most SysAid configurations. Add custom fields only after confirming the field keys in your specific SysAid instance.
  • Show a loading spinner during the login + create chain and disable the Submit button to prevent double-submissions.

Alternatives

Frequently asked questions

Can FlutterFlow users log in with their own SysAid accounts, or does the app use a shared service account?

It depends on your architecture. With the direct FlutterFlow API Call approach covered here, each user would need their own SysAid credentials to log in — the app stores their personal JSESSIONID in App State. With the Cloud Function proxy approach, the proxy uses a shared service account and the FlutterFlow app authenticates users via Firebase Auth instead; this is the recommended pattern for most employee-facing apps.

Does SysAid's REST API have a free tier for testing?

SysAid is quote-based enterprise software with no public free tier or sandbox environment. You need an active SysAid account with API access enabled by your SysAid administrator. Contact your IT team to confirm API access is available on your license.

What happens when the SysAid session cookie expires while the app is open?

SysAid sessions expire after a configurable idle period (typically 30–60 minutes). When the session expires, the next API call returns 401 Unauthorized. The recommended approach is to detect 401 in the Action Flow, clear the sysAidCookie App State variable, re-run the login action, update App State with the new cookie, and retry the original call — transparent to the user.

Can the FlutterFlow app list existing tickets as well as create new ones?

Yes. Add another API Call to the SysAid API Group — a GET /sr call with the Cookie header forwarded from App State. Parse the response array into a FlutterFlow list widget. You can filter by status, assigned user, or date range using SysAid's query parameters to keep the list manageable.

Will this integration work on both iOS and Android, and on web?

The Custom Action (Dart) for cookie capture runs on iOS and Android. FlutterFlow web builds add a CORS consideration: the SysAid server must allow browser origins, which most enterprise ITSM servers do not configure by default. Web builds will likely require the Cloud Function proxy approach, where the proxy handles SysAid and the browser communicates only with your own proxy domain.

RapidDev

Talk to an Expert

Our team has built 600+ apps. Get personalized help with your project.

Book a free consultation

Integrations are where projects stall

We wire FlutterFlow integrations like this one every week — auth, webhooks, edge cases included. Fixed-price builds from $13K, delivered in 6–10 weeks.

Talk to an integration engineer

We put the rapid in RapidDev

Need a dedicated strategic tech and growth partner? Discover what RapidDev can do for your business! Book a call with our team to schedule a free, no-obligation consultation. We'll discuss your project and provide a custom quote at no cost.