swift Client Library

You can initialize Supabase with the SupabaseClient by passing your Project URL and Project Key. You can find these under your Project Settings → API Settings The Supabase client is your entrypoint to the rest of the Supabase functionality and is the easiest way to interact with everything we offer within the Supabase ecosystem.

• By default, Supabase projects will return a maximum of 1,000 rows. This setting can be changed in Project API Settings. It's recommended that you keep it low to limit the payload size of accidental or malicious requests. You can use range() queries to paginate through your data.
• select() can be combined with Modifiers
• select() can be combined with Filters
• If using the Supabase hosted platform apikey is technically a reserved keyword, since the API gateway will pluck it out for authentication. It should be avoided as a column name.
• The recommended solution for getting data is to use the value property which will return a decoded model. Create a Codable to easily decode your database responses.

• update() should always be combined with Filters to target the item(s) you wish to update.

• Primary keys must be included in values to use upsert.

• delete() should always be combined with filters to target the item(s) you wish to delete.
• If you use delete() with filters and you have RLS enabled, only rows visible through SELECT policies are deleted. Note that by default no rows are visible, so you need at least one SELECT/ALL policy that makes the rows visible.

You can call Postgres functions as Remote Procedure Calls, logic in your database that you can execute from anywhere. Functions are useful when the logic rarely changes—like for password resets and updates.

Filters allow you to only return rows that match certain conditions.

Filters can be used on select(), update(), upsert(), and delete() queries.

If a Postgres function returns a table response, you can also apply filters.

Implement URLQueryRepresentable protocol in your own types to be able to use them as filter value.

Supported filtes are: eq, neq, gt, gte, lt, lte, like, ilike, is, in, cs, cd, sl, sr, nxl, nxr, adj, ov, fts, plfts, phfts, wfts. Check available operators in PostgREST.

Finds all rows that don't satisfy the filter.

• .not() expects you to use the raw PostgREST syntax for the filter names and values.

  
  

  _10

  .not("name", operator: .eq, value: "Paris")

  _10

  .not("arraycol", operator: .cs, value: #"{"a","b"}"#) // Use Postgres array {} for array column and 'cs' for contains.

  _10

  .not("rangecol", operator: .cs, value: "(1,2]") // Use Postgres range syntax for range column.

  _10

  .not("id", operator: .in, value: "(6,7)") // Use Postgres list () and 'in' for in_ filter.

  _10

  .not("id", operator: .in, value: "(\(mylist.join(separator: ",")))") // You can insert a Swift list array.

  
  

or() expects you to use the raw PostgREST syntax for the filter names and values.

filter() expects you to use the raw PostgREST syntax for the filter values.

Filters work on the row level—they allow you to return rows that only match certain conditions without changing the shape of the rows. Modifiers are everything that don't fit that definition—allowing you to change the format of the response (e.g. returning a CSV string).

Modifiers must be specified after filters. Some modifiers only apply for queries that return rows (e.g., select() or rpc() on a function that returns a table response).

Perform a SELECT on the query result.

Order the query result by column.

Limit the query result by count.

Limit the query result by from and to inclusively.

By default PostgREST returns all JSON results in an array, even when there is only one item, use single() to return the first object unenclosed by an array.

• The auth methods can be accessed via the supabase.auth namespace.

• By default, the user needs to verify their email address before logging in. To turn this off, disable Confirm email in your project.
• Confirm email determines if users need to confirm their email address after signing up.
  • If Confirm email is enabled, a user is returned but session is null.
  • If Confirm email is disabled, both a user and a session are returned.
• When the user confirms their email address, they are redirected to the SITE_URL by default. You can modify your SITE_URL or add additional redirect URLs in your project.
• If signUp() is called for an existing confirmed user:
  • If Confirm email is enabled in your project, an obfuscated/fake user object is returned.
  • If Confirm email is disabled, the error message, User already registered is returned.
• To fetch the currently logged-in user, refer to getUser().

• Types of auth events: INITIAL_SESSION, SIGNED_IN, SIGNED_OUT, TOKEN_REFRESHED, USER_UPDATED, PASSWORD_RECOVERY, MFA_CHALLENGE_VERIFIED
• The INITIAL_SESSION can be used to allow you to invoke the callback function when authStateChanges is first called.

• Requires either an email and password or a phone number and password.

• This method is used for passwordless sign-ins where a OTP is sent to the user's email or phone number.
• If the user doesn't exist, signInWithOTP() will signup the user instead. To restrict this behavior, you can set shouldCreateUser to false.
• If you're using an email, you can configure whether you want the user to receive a magiclink or a OTP.
• If you're using phone, you can configure whether you want the user to receive a OTP.
• The magic link's destination URL is determined by the SITE_URL.
• See redirect URLs and wildcards to add additional redirect URLs to your project.
• Magic links and OTPs share the same implementation. To send users a one-time code instead of a magic link, modify the magic link email template to include {{ .Token }} instead of {{ .ConfirmationURL }}.
• When using magic links, specify a redirectTo that matches a configured url scheme in your iOS app, so Supabase can correctly redirect back to your app.
• See our Twilio Phone Auth Guide for details about configuring WhatsApp sign in.

• This method is used for signing in using a third-party provider.
• Supabase supports many different third-party providers.

• In order to use the signOut() method, the user needs to be signed in first.

• The verifyOTP method takes in different verification types. If a phone number is used, the type can either be sms or phone_change. If an email address is used, the type can be one of the following: signup, magiclink, recovery, invite, email_change, or email.
• The verification type used should be determined based on the corresponding auth method called before verifyOTP to sign up / sign-in a user.

• Returns the session, refreshing it if necessary. If no session can be found, a GoTrueError.sessionNotFound error is thrown.

• This method will refresh the session whether the current one is expired or not.

• This method is useful for checking if the user is authorized because it validates the user's access token JWT on the server.
• Fetches the user object from the database instead of local session.
• Should be used only when you require the most current user data. For faster results, session.user is recommended.

• In order to use the updateUser() method, the user needs to be signed in first.
• By default, email updates sends a confirmation link to both the user's current and new email. To only send a confirmation link to the user's new email, disable Secure email change in your project's email auth provider settings.

• setSession() takes in a refresh token and uses it to get a new session.
• The refresh token can only be used once to obtain a new session.
• Refresh token rotation is enabled by default on all projects to guard against replay attacks.
• You can configure the REFRESH_TOKEN_REUSE_INTERVAL which provides a short window in which the same refresh token can be used multiple times in the event of concurrency or offline issues.

• Used when flowType is set to pkce in client options.

This section contains methods commonly used for Multi-Factor Authentication (MFA) and are invoked behind the supabase.auth.mfa namespace.

Currently, we only support time-based one-time password (TOTP) as the 2nd factor. We don't support recovery codes but we allow users to enroll more than 1 TOTP factor, with an upper limit of 10.

Having a 2nd TOTP factor for recovery frees the user of the burden of having to store their recovery codes somewhere. It also reduces the attack surface since multiple recovery codes are usually generated compared to just having 1 backup TOTP factor.

• Currently, totp is the only supported factorType. The returned id should be used to create a challenge.
• To create a challenge, see mfa.challenge().
• To verify a challenge, see mfa.verify().
• To create and verify a challenge in a single step, see mfa.challengeAndVerify().

• An enrolled factor is required before creating a challenge.
• To verify a challenge, see mfa.verify().

• To verify a challenge, please create a challenge first.

• An enrolled factor is required before invoking challengeAndVerify().
• Executes mfa.challenge() and mfa.verify() in a single step.

• Authenticator Assurance Level (AAL) is the measure of the strength of an authentication mechanism.
• In Supabase, having an AAL of aal1 refers to having the 1st factor of authentication such as an email and password or OAuth sign-in while aal2 refers to the 2nd factor of authentication such as a time-based, one-time-password (TOTP).
• If the user has a verified factor, the nextLevel field will return aal2, else, it will return aal1.

Invoke a Supabase Edge Function.

• Requires an Authorization header.
• When you pass in a body to your function, we automatically attach the Content-Type header for String, and Data. If it doesn't match any of these types we assume the payload is json, serialize it and attach the Content-Type header as application/json. You can override this behaviour by passing in a Content-Type header of your own.

• By default, Broadcast and Presence are enabled for all projects.
• By default, listening to database changes is disabled for new projects due to database performance and security concerns. You can turn it on by managing Realtime's replication.
• You can receive the "previous" data for updates and deletes by setting the table's REPLICA IDENTITY to FULL (e.g., ALTER TABLE your_table REPLICA IDENTITY FULL;).
• Row level security is not applied to delete statements. When RLS is enabled and replica identity is set to full, only the primary key is sent to clients.

• Removing a channel is a great way to maintain the performance of your project's Realtime service as well as your database if you're listening to Postgres changes. Supabase will automatically handle cleanup 30 seconds after a client is disconnected, but unused channels may cause degradation as more clients are simultaneously subscribed.

• Removing channels is a great way to maintain the performance of your project's Realtime service as well as your database if you're listening to Postgres changes. Supabase will automatically handle cleanup 30 seconds after a client is disconnected, but unused channels may cause degradation as more clients are simultaneously subscribed.

Broadcast a message to all connected clients to a channel.

• When using REST you don't need to subscribe to the channel

• RLS policy permissions required:
  • buckets table permissions: insert
  • objects table permissions: none
• Refer to the Storage guide on how access control works

• RLS policy permissions required:
  • buckets table permissions: select
  • objects table permissions: none
• Refer to the Storage guide on how access control works

• RLS policy permissions required:
  • buckets table permissions: select
  • objects table permissions: none
• Refer to the Storage guide on how access control works

• RLS policy permissions required:
  • buckets table permissions: select and update
  • objects table permissions: none
• Refer to the Storage guide on how access control works

• RLS policy permissions required:
  • buckets table permissions: select and delete
  • objects table permissions: none
• Refer to the Storage guide on how access control works

• RLS policy permissions required:
  • buckets table permissions: select
  • objects table permissions: select and delete
• Refer to the Storage guide on how access control works

• RLS policy permissions required:
  • buckets table permissions: none
  • objects table permissions: only insert when you are uploading new files and select, insert and update when you are upserting files
• Refer to the Storage guide on how access control works

• RLS policy permissions required:
  • buckets table permissions: none
  • objects table permissions: select
• Refer to the Storage guide on how access control works

• RLS policy permissions required:
  • buckets table permissions: none
  • objects table permissions: select
• Refer to the Storage guide on how access control works

• RLS policy permissions required:
  • buckets table permissions: none
  • objects table permissions: update and select
• Refer to the Storage guide on how access control works

• RLS policy permissions required:
  • buckets table permissions: none
  • objects table permissions: update and select
• Refer to the Storage guide on how access control works

• RLS policy permissions required:
  • buckets table permissions: none
  • objects table permissions: insert and select
• Refer to the Storage guide on how access control works

• RLS policy permissions required:
  • buckets table permissions: none
  • objects table permissions: delete and select
• Refer to the Storage guide on how access control works

• RLS policy permissions required:
  • buckets table permissions: none
  • objects table permissions: select
• Refer to the Storage guide on how access control works

• The bucket needs to be set to public, either via updateBucket() or by going to Storage on supabase.com/dashboard, clicking the overflow menu on a bucket and choosing "Make public"
• RLS policy permissions required:
  • buckets table permissions: none
  • objects table permissions: none
• Refer to the Storage guide on how access control works