Genesys Cloud - Developer Community!

If you've spent time working with Genesys Cloud APIs, you already understand more about the CLI than you might think.

I used to look at CLI commands and feel like they belonged in a different world. But once I started mapping them back to REST APIs, it clicked: it's the same conversation with the platform, just written differently.

So here's a simple way to think about it.

The REST API structure (the one most of us know):
METHOD /url-endpoint?query=params&expand=...

Example:
GET /api/v2/users?pageSize=25&expand=presence

In plain terms:
"Get me a list of users, limit it to 25, and include their presence information."

Now let's look at the CLI version of that same request.

The CLI structure:
gc <resource> <command> --flag value

Example:
gc users list --pageSize 25 --expand presence

Same request. Same outcome. Just a different way of asking.

Here's how the pieces map:

• METHOD (GET, POST, PUT, DELETE) → becomes the command (list, create, update, delete)

• Endpoint (/api/v2/users) → becomes the resource (users)

• Query params (?pageSize=25&expand=presence) → become flags (--pageSize 25 --expand presence)

Once you see this, the CLI stops feeling new. It's just a more direct way to work with the API.

A few flags you'll see all the time:

• --expand
  Ask for additional related data. Instead of making multiple calls, you bring more context into one response.

• --pageSize
  Control how many results come back. Useful when you're testing or trying to limit output.

• --pageNumber
  Move through paginated results. Same idea as API pagination, just cleaner to type.

• --id
  Target a specific object. Instead of filtering a list, you go straight to what you need.

• --name
  Often used when creating or filtering resources in a more human-readable way.

• --file
  Pass a JSON payload from a file. This is especially useful for create/update operations where typing everything inline would be painful.

The more you work with both, the more you realize:

The API asks through HTTP.
The CLI asks through commands.
But both are asking Genesys Cloud to do the exact same thing.

And sometimes, the CLI is just the faster way to say it. 

If you want to learn more about APIs in Genesys Cloud, do not forget to checkout the resources available at Genesys Education, specially our Workshop on Genesys CLI.

Curious to hear from others: do you tend to reach for APIs or the CLI first when working in Genesys Cloud - and why?

If you've spent time working with Genesys Cloud APIs, you already understand more about the CLI than you might think.

I used to look at CLI commands and feel like they belonged in a different world. But once I started mapping them back to REST APIs, it clicked: it's the same conversation with the platform, just written differently.

So here's a simple way to think about it.

The REST API structure (the one most of us know):
METHOD /url-endpoint?query=params&expand=...

Example:
GET /api/v2/users?pageSize=25&expand=presence

In plain terms:
"Get me a list of users, limit it to 25, and include their presence information."

Now let's look at the CLI version of that same request.

The CLI structure:
gc <resource> <command> --flag value

Example:
gc users list --pageSize 25 --expand presence

Same request. Same outcome. Just a different way of asking.

Here's how the pieces map:

• METHOD (GET, POST, PUT, DELETE) → becomes the command (list, create, update, delete)

• Endpoint (/api/v2/users) → becomes the resource (users)

• Query params (?pageSize=25&expand=presence) → become flags (--pageSize 25 --expand presence)

Once you see this, the CLI stops feeling new. It's just a more direct way to work with the API.

A few flags you'll see all the time:

• --expand
  Ask for additional related data. Instead of making multiple calls, you bring more context into one response.

• --pageSize
  Control how many results come back. Useful when you're testing or trying to limit output.

• --pageNumber
  Move through paginated results. Same idea as API pagination, just cleaner to type.

• --id
  Target a specific object. Instead of filtering a list, you go straight to what you need.

• --name
  Often used when creating or filtering resources in a more human-readable way.

• --file
  Pass a JSON payload from a file. This is especially useful for create/update operations where typing everything inline would be painful.

The more you work with both, the more you realize:

The API asks through HTTP.
The CLI asks through commands.
But both are asking Genesys Cloud to do the exact same thing.

And sometimes, the CLI is just the faster way to say it. 

If you want to learn more about APIs in Genesys Cloud, do not forget to checkout the resources available at Genesys Education, specially our Workshop on Genesys CLI.

Curious to hear from others: do you tend to reach for APIs or the CLI first when working in Genesys Cloud - and why?

If you've spent time working with Genesys Cloud APIs, you already understand more about the CLI than you might think.

I used to look at CLI commands and feel like they belonged in a different world. But once I started mapping them back to REST APIs, it clicked: it's the same conversation with the platform, just written differently.

So here's a simple way to think about it.

The REST API structure (the one most of us know):
METHOD /url-endpoint?query=params&expand=...

Example:
GET /api/v2/users?pageSize=25&expand=presence

In plain terms:
"Get me a list of users, limit it to 25, and include their presence information."

Now let's look at the CLI version of that same request.

The CLI structure:
gc <resource> <command> --flag value

Example:
gc users list --pageSize 25 --expand presence

Same request. Same outcome. Just a different way of asking.

Here's how the pieces map:

• METHOD (GET, POST, PUT, DELETE) → becomes the command (list, create, update, delete)

• Endpoint (/api/v2/users) → becomes the resource (users)

• Query params (?pageSize=25&expand=presence) → become flags (--pageSize 25 --expand presence)

Once you see this, the CLI stops feeling new. It's just a more direct way to work with the API.

A few flags you'll see all the time:

• --expand
  Ask for additional related data. Instead of making multiple calls, you bring more context into one response.

• --pageSize
  Control how many results come back. Useful when you're testing or trying to limit output.

• --pageNumber
  Move through paginated results. Same idea as API pagination, just cleaner to type.

• --id
  Target a specific object. Instead of filtering a list, you go straight to what you need.

• --name
  Often used when creating or filtering resources in a more human-readable way.

• --file
  Pass a JSON payload from a file. This is especially useful for create/update operations where typing everything inline would be painful.

The more you work with both, the more you realize:

The API asks through HTTP.
The CLI asks through commands.
But both are asking Genesys Cloud to do the exact same thing.

And sometimes, the CLI is just the faster way to say it. 

If you want to learn more about APIs in Genesys Cloud, do not forget to checkout the resources available at Genesys Education, specially our Workshop on Genesys CLI.

Curious to hear from others: do you tend to reach for APIs or the CLI first when working in Genesys Cloud - and why?

Hi Rodrigo,

usally I tend to use the API explorer to learn new functionality and mostly because I then can create a data action from what I learned. But for repeating jobs I really love to use CLI.

Because we can't use terraform I do my backups via CLI. Its so easy with CLI that everyone that reads my backup-manual can use it - just simply copy & paste the commands.

I find CLI pretty handy when creating new users. I have a set of CLI-commands that help me to do the job in half of the time I need manually.

If you've spent time working with Genesys Cloud APIs, you already understand more about the CLI than you might think.

I used to look at CLI commands and feel like they belonged in a different world. But once I started mapping them back to REST APIs, it clicked: it's the same conversation with the platform, just written differently.

So here's a simple way to think about it.

The REST API structure (the one most of us know):
METHOD /url-endpoint?query=params&expand=...

Example:
GET /api/v2/users?pageSize=25&expand=presence

In plain terms:
"Get me a list of users, limit it to 25, and include their presence information."

Now let's look at the CLI version of that same request.

The CLI structure:
gc <resource> <command> --flag value

Example:
gc users list --pageSize 25 --expand presence

Same request. Same outcome. Just a different way of asking.

Here's how the pieces map:

• METHOD (GET, POST, PUT, DELETE) → becomes the command (list, create, update, delete)

• Endpoint (/api/v2/users) → becomes the resource (users)

• Query params (?pageSize=25&expand=presence) → become flags (--pageSize 25 --expand presence)

Once you see this, the CLI stops feeling new. It's just a more direct way to work with the API.

A few flags you'll see all the time:

• --expand
  Ask for additional related data. Instead of making multiple calls, you bring more context into one response.

• --pageSize
  Control how many results come back. Useful when you're testing or trying to limit output.

• --pageNumber
  Move through paginated results. Same idea as API pagination, just cleaner to type.

• --id
  Target a specific object. Instead of filtering a list, you go straight to what you need.

• --name
  Often used when creating or filtering resources in a more human-readable way.

• --file
  Pass a JSON payload from a file. This is especially useful for create/update operations where typing everything inline would be painful.

The more you work with both, the more you realize:

The API asks through HTTP.
The CLI asks through commands.
But both are asking Genesys Cloud to do the exact same thing.

And sometimes, the CLI is just the faster way to say it. 

If you want to learn more about APIs in Genesys Cloud, do not forget to checkout the resources available at Genesys Education, specially our Workshop on Genesys CLI.

Curious to hear from others: do you tend to reach for APIs or the CLI first when working in Genesys Cloud - and why?

Hi @Christoph Domaschke,

Can you tell me a little more about what you mean when you say you do your backups via CLI? What are you backing up, how?

Hi Rodrigo,

usally I tend to use the API explorer to learn new functionality and mostly because I then can create a data action from what I learned. But for repeating jobs I really love to use CLI.

Because we can't use terraform I do my backups via CLI. Its so easy with CLI that everyone that reads my backup-manual can use it - just simply copy & paste the commands.

I find CLI pretty handy when creating new users. I have a set of CLI-commands that help me to do the job in half of the time I need manually.

If you've spent time working with Genesys Cloud APIs, you already understand more about the CLI than you might think.

I used to look at CLI commands and feel like they belonged in a different world. But once I started mapping them back to REST APIs, it clicked: it's the same conversation with the platform, just written differently.

So here's a simple way to think about it.

The REST API structure (the one most of us know):
METHOD /url-endpoint?query=params&expand=...

Example:
GET /api/v2/users?pageSize=25&expand=presence

In plain terms:
"Get me a list of users, limit it to 25, and include their presence information."

Now let's look at the CLI version of that same request.

The CLI structure:
gc <resource> <command> --flag value

Example:
gc users list --pageSize 25 --expand presence

Same request. Same outcome. Just a different way of asking.

Here's how the pieces map:

• METHOD (GET, POST, PUT, DELETE) → becomes the command (list, create, update, delete)

• Endpoint (/api/v2/users) → becomes the resource (users)

• Query params (?pageSize=25&expand=presence) → become flags (--pageSize 25 --expand presence)

Once you see this, the CLI stops feeling new. It's just a more direct way to work with the API.

A few flags you'll see all the time:

• --expand
  Ask for additional related data. Instead of making multiple calls, you bring more context into one response.

• --pageSize
  Control how many results come back. Useful when you're testing or trying to limit output.

• --pageNumber
  Move through paginated results. Same idea as API pagination, just cleaner to type.

• --id
  Target a specific object. Instead of filtering a list, you go straight to what you need.

• --name
  Often used when creating or filtering resources in a more human-readable way.

• --file
  Pass a JSON payload from a file. This is especially useful for create/update operations where typing everything inline would be painful.

The more you work with both, the more you realize:

The API asks through HTTP.
The CLI asks through commands.
But both are asking Genesys Cloud to do the exact same thing.

And sometimes, the CLI is just the faster way to say it. 

If you want to learn more about APIs in Genesys Cloud, do not forget to checkout the resources available at Genesys Education, specially our Workshop on Genesys CLI.

Curious to hear from others: do you tend to reach for APIs or the CLI first when working in Genesys Cloud - and why?

Hi @James Dunn,

I do not backup all components via CLI, just that ones, that are not good do backup via UI. Here is my (german) list. Please use an AI-bot for translation:

Flow-Outcomes

gc flows outcomes list --autopaginate > 01_flow_outcomes.json

und die Milestones, die im Flow verwendet werden:

gc flows milestones list --autopaginate > 02_flow_milestones.json

Queues können nicht über das User-Interface (UI) exportiert werden. Das CLI (Command Line Interface) ist am besten geeignet:

gc routing queues list --autopaginate > queues.json

Liste der Prompts mit CLI gezogen werden:

gc architect prompts list --includeMediaUris true  --includeResources true --autopaginate > prompts.json

Skills and languages:

gc routing skills list --autopaginate > skills.json

gc routing languages list --autopaginate > languages.json

Shedules & shedule groups:

gc architect schedules list --autopaginate > schedules.json

gc architect schedulegroups list --autopaginate > schedulegroups.json

Emergency groups:
gc architect emergencygroups list --autopaginate > emergencygroups.json

Sites and locations:

gc telephony providers edges sites list --autopaginate > sites.json

gc locations list --autopaginate > locations.json

Trunks and base trunk settings:

gc telephony providers edges trunkbasesettings list --autopaginate > trunkbasesettings.json

gc telephony providers edges trunks list --autopaginate > trunks.json

Edges and Edge groups:

gc telephony providers edges list --autopaginate > edges.json

gc telephony providers edges edgegroups list --autopaginate > edgegroups.json

Die Zertifizierungsstellen werden so erfasst:

gc telephony providers edges certificateauthorities list --autopaginate > certificate_authorities.json

Side-ID kann man der gezogenen Site-Liste entnehmen. Pro Site muss ein numberplan gezogen werden.

gc telephony providers edges outboundroutes list --autopaginate > outboundroutes.json

gc telephony providers edges sites numberplans list 471ba2a6-xxxx-418e-bd9c-23593485f8ba > DreieichTestsite.json

Phone base settings and phones

gc telephony providers edges phonebasesettings list --autopaginate > phonebasesettings.json

gc telephony providers edges phones list --autopaginate > phones.json

Roles
gc authorization roles list --autopaginate > roles.json

17 Groups und Nutzer
gc groups list --autopaginate > groups.json
gc users list --expand "groups" --autopaginate > users_groups.json 
gc users list --expand "authorization" --autopaginate > users_with_roles.json

19 Divisions
gc authorization divisions list --autopaginate > divisions.json

20 Wrapup Codes
gc routing wrapupcodes list --autopaginate > wrapupcodes.json

DIDs
gc telephony providers edges dids list --autopaginate > DID_list.json

23 oAuths
gc oauth clients list --autopaginate > oAuth_clients.json

24 Integrations
gc integrations list --autopaginate > integrations_list.json

25 Email
gc routing email domains list --autopaginate > emaildomains.json
Für jede darin enthaltene E-Mail-Domain:
gc routing email domains routes list cronbank.de --autopaginate > emailroutes_cronbank.de.json

26 Trigger
Gesicherte Trigger enthalten nur einen Verweis auf die Workflow-ID, was herzlich wenig bringt, wenn die Flows nach einem Totalausfall neu aufgebaut werden müssen. Entsprechend muss für jeden Trigger eine sinnvolle Discription verfasst werden, was die Aufgabe des Triggers ist und auf welchen Workflow sie namentlich verweist.
gc processautomation triggers list --autopaginate > triggers.json

Kampagnenliste:

gc outbound campaigns list --autopaginate > outbound_campaigns.json

Kampagnen-Regeln (Stand 26.9.25 leer):

gc outbound campaignrules list --autopaginate > outbound_campaginrules.json

Liste der Kontaktlisten:

gc outbound contactlists list --autopaginate > outbound_contactlists.json

è Einzelne aktuelle Kontaktlisten via UI runterladen. Dazu gehören auch die NoCall-Detections.

Regelsets:

gc outbound rulesets list --autopaginate > outbound_rulesets.json

Outbound-Einstellungen:

gc outbound settings get > outbound_settings.json

Hi @Christoph Domaschke,

Can you tell me a little more about what you mean when you say you do your backups via CLI? What are you backing up, how?

Hi Rodrigo,

usally I tend to use the API explorer to learn new functionality and mostly because I then can create a data action from what I learned. But for repeating jobs I really love to use CLI.

Because we can't use terraform I do my backups via CLI. Its so easy with CLI that everyone that reads my backup-manual can use it - just simply copy & paste the commands.

I find CLI pretty handy when creating new users. I have a set of CLI-commands that help me to do the job in half of the time I need manually.

If you've spent time working with Genesys Cloud APIs, you already understand more about the CLI than you might think.

I used to look at CLI commands and feel like they belonged in a different world. But once I started mapping them back to REST APIs, it clicked: it's the same conversation with the platform, just written differently.

So here's a simple way to think about it.

The REST API structure (the one most of us know):
METHOD /url-endpoint?query=params&expand=...

Example:
GET /api/v2/users?pageSize=25&expand=presence

In plain terms:
"Get me a list of users, limit it to 25, and include their presence information."

Now let's look at the CLI version of that same request.

The CLI structure:
gc <resource> <command> --flag value

Example:
gc users list --pageSize 25 --expand presence

Same request. Same outcome. Just a different way of asking.

Here's how the pieces map:

• METHOD (GET, POST, PUT, DELETE) → becomes the command (list, create, update, delete)

• Endpoint (/api/v2/users) → becomes the resource (users)

• Query params (?pageSize=25&expand=presence) → become flags (--pageSize 25 --expand presence)

Once you see this, the CLI stops feeling new. It's just a more direct way to work with the API.

A few flags you'll see all the time:

• --expand
  Ask for additional related data. Instead of making multiple calls, you bring more context into one response.

• --pageSize
  Control how many results come back. Useful when you're testing or trying to limit output.

• --pageNumber
  Move through paginated results. Same idea as API pagination, just cleaner to type.

• --id
  Target a specific object. Instead of filtering a list, you go straight to what you need.

• --name
  Often used when creating or filtering resources in a more human-readable way.

• --file
  Pass a JSON payload from a file. This is especially useful for create/update operations where typing everything inline would be painful.

The more you work with both, the more you realize:

The API asks through HTTP.
The CLI asks through commands.
But both are asking Genesys Cloud to do the exact same thing.

And sometimes, the CLI is just the faster way to say it. 

If you want to learn more about APIs in Genesys Cloud, do not forget to checkout the resources available at Genesys Education, specially our Workshop on Genesys CLI.

Curious to hear from others: do you tend to reach for APIs or the CLI first when working in Genesys Cloud - and why?

This is something you run on a recurring basis, and backup all those each time? Or are you just backing up bits and pieces as you go?

Like before you delete a user you backup the users etc? 

Just interested to see how you are using it, it's a good idea and not something I had considered, but it's something that would be easy to implement. Could create a cron job to get a local backup of the platform (partly) each week.

Hi @James Dunn,

I do not backup all components via CLI, just that ones, that are not good do backup via UI. Here is my (german) list. Please use an AI-bot for translation:

Flow-Outcomes

gc flows outcomes list --autopaginate > 01_flow_outcomes.json

und die Milestones, die im Flow verwendet werden:

gc flows milestones list --autopaginate > 02_flow_milestones.json

Queues können nicht über das User-Interface (UI) exportiert werden. Das CLI (Command Line Interface) ist am besten geeignet:

gc routing queues list --autopaginate > queues.json

Liste der Prompts mit CLI gezogen werden:

gc architect prompts list --includeMediaUris true  --includeResources true --autopaginate > prompts.json

Skills and languages:

gc routing skills list --autopaginate > skills.json

gc routing languages list --autopaginate > languages.json

Shedules & shedule groups:

gc architect schedules list --autopaginate > schedules.json

gc architect schedulegroups list --autopaginate > schedulegroups.json

Emergency groups:
gc architect emergencygroups list --autopaginate > emergencygroups.json

Sites and locations:

gc telephony providers edges sites list --autopaginate > sites.json

gc locations list --autopaginate > locations.json

Trunks and base trunk settings:

gc telephony providers edges trunkbasesettings list --autopaginate > trunkbasesettings.json

gc telephony providers edges trunks list --autopaginate > trunks.json

Edges and Edge groups:

gc telephony providers edges list --autopaginate > edges.json

gc telephony providers edges edgegroups list --autopaginate > edgegroups.json

Die Zertifizierungsstellen werden so erfasst:

gc telephony providers edges certificateauthorities list --autopaginate > certificate_authorities.json

Side-ID kann man der gezogenen Site-Liste entnehmen. Pro Site muss ein numberplan gezogen werden.

gc telephony providers edges outboundroutes list --autopaginate > outboundroutes.json

gc telephony providers edges sites numberplans list 471ba2a6-xxxx-418e-bd9c-23593485f8ba > DreieichTestsite.json

Phone base settings and phones

gc telephony providers edges phonebasesettings list --autopaginate > phonebasesettings.json

gc telephony providers edges phones list --autopaginate > phones.json

Roles
gc authorization roles list --autopaginate > roles.json

17 Groups und Nutzer
gc groups list --autopaginate > groups.json
gc users list --expand "groups" --autopaginate > users_groups.json 
gc users list --expand "authorization" --autopaginate > users_with_roles.json

19 Divisions
gc authorization divisions list --autopaginate > divisions.json

20 Wrapup Codes
gc routing wrapupcodes list --autopaginate > wrapupcodes.json

DIDs
gc telephony providers edges dids list --autopaginate > DID_list.json

23 oAuths
gc oauth clients list --autopaginate > oAuth_clients.json

24 Integrations
gc integrations list --autopaginate > integrations_list.json

25 Email
gc routing email domains list --autopaginate > emaildomains.json
Für jede darin enthaltene E-Mail-Domain:
gc routing email domains routes list cronbank.de --autopaginate > emailroutes_cronbank.de.json

26 Trigger
Gesicherte Trigger enthalten nur einen Verweis auf die Workflow-ID, was herzlich wenig bringt, wenn die Flows nach einem Totalausfall neu aufgebaut werden müssen. Entsprechend muss für jeden Trigger eine sinnvolle Discription verfasst werden, was die Aufgabe des Triggers ist und auf welchen Workflow sie namentlich verweist.
gc processautomation triggers list --autopaginate > triggers.json

Kampagnenliste:

gc outbound campaigns list --autopaginate > outbound_campaigns.json

Kampagnen-Regeln (Stand 26.9.25 leer):

gc outbound campaignrules list --autopaginate > outbound_campaginrules.json

Liste der Kontaktlisten:

gc outbound contactlists list --autopaginate > outbound_contactlists.json

è Einzelne aktuelle Kontaktlisten via UI runterladen. Dazu gehören auch die NoCall-Detections.

Regelsets:

gc outbound rulesets list --autopaginate > outbound_rulesets.json

Outbound-Einstellungen:

gc outbound settings get > outbound_settings.json

Hi @Christoph Domaschke,

Can you tell me a little more about what you mean when you say you do your backups via CLI? What are you backing up, how?

Hi Rodrigo,

usally I tend to use the API explorer to learn new functionality and mostly because I then can create a data action from what I learned. But for repeating jobs I really love to use CLI.

Because we can't use terraform I do my backups via CLI. Its so easy with CLI that everyone that reads my backup-manual can use it - just simply copy & paste the commands.

I find CLI pretty handy when creating new users. I have a set of CLI-commands that help me to do the job in half of the time I need manually.

If you've spent time working with Genesys Cloud APIs, you already understand more about the CLI than you might think.

I used to look at CLI commands and feel like they belonged in a different world. But once I started mapping them back to REST APIs, it clicked: it's the same conversation with the platform, just written differently.

So here's a simple way to think about it.

The REST API structure (the one most of us know):
METHOD /url-endpoint?query=params&expand=...

Example:
GET /api/v2/users?pageSize=25&expand=presence

In plain terms:
"Get me a list of users, limit it to 25, and include their presence information."

Now let's look at the CLI version of that same request.

The CLI structure:
gc <resource> <command> --flag value

Example:
gc users list --pageSize 25 --expand presence

Same request. Same outcome. Just a different way of asking.

Here's how the pieces map:

• METHOD (GET, POST, PUT, DELETE) → becomes the command (list, create, update, delete)

• Endpoint (/api/v2/users) → becomes the resource (users)

• Query params (?pageSize=25&expand=presence) → become flags (--pageSize 25 --expand presence)

Once you see this, the CLI stops feeling new. It's just a more direct way to work with the API.

A few flags you'll see all the time:

• --expand
  Ask for additional related data. Instead of making multiple calls, you bring more context into one response.

• --pageSize
  Control how many results come back. Useful when you're testing or trying to limit output.

• --pageNumber
  Move through paginated results. Same idea as API pagination, just cleaner to type.

• --id
  Target a specific object. Instead of filtering a list, you go straight to what you need.

• --name
  Often used when creating or filtering resources in a more human-readable way.

• --file
  Pass a JSON payload from a file. This is especially useful for create/update operations where typing everything inline would be painful.

The more you work with both, the more you realize:

The API asks through HTTP.
The CLI asks through commands.
But both are asking Genesys Cloud to do the exact same thing.

And sometimes, the CLI is just the faster way to say it. 

If you want to learn more about APIs in Genesys Cloud, do not forget to checkout the resources available at Genesys Education, specially our Workshop on Genesys CLI.

Curious to hear from others: do you tend to reach for APIs or the CLI first when working in Genesys Cloud - and why?

Yes, i do all components on recurring basis. If you copy paste all commands into the command line in one stept it executes all of them automaticly.
For me this solution is "better than nothing" and I really hope not to rebuild the system one day with that backups. 

A cron job is a great idea, thanks for that!

This is something you run on a recurring basis, and backup all those each time? Or are you just backing up bits and pieces as you go?

Like before you delete a user you backup the users etc? 

Just interested to see how you are using it, it's a good idea and not something I had considered, but it's something that would be easy to implement. Could create a cron job to get a local backup of the platform (partly) each week.

Hi @James Dunn,

I do not backup all components via CLI, just that ones, that are not good do backup via UI. Here is my (german) list. Please use an AI-bot for translation:

Flow-Outcomes

gc flows outcomes list --autopaginate > 01_flow_outcomes.json

und die Milestones, die im Flow verwendet werden:

gc flows milestones list --autopaginate > 02_flow_milestones.json

Queues können nicht über das User-Interface (UI) exportiert werden. Das CLI (Command Line Interface) ist am besten geeignet:

gc routing queues list --autopaginate > queues.json

Liste der Prompts mit CLI gezogen werden:

gc architect prompts list --includeMediaUris true  --includeResources true --autopaginate > prompts.json

Skills and languages:

gc routing skills list --autopaginate > skills.json

gc routing languages list --autopaginate > languages.json

Shedules & shedule groups:

gc architect schedules list --autopaginate > schedules.json

gc architect schedulegroups list --autopaginate > schedulegroups.json

Emergency groups:
gc architect emergencygroups list --autopaginate > emergencygroups.json

Sites and locations:

gc telephony providers edges sites list --autopaginate > sites.json

gc locations list --autopaginate > locations.json

Trunks and base trunk settings:

gc telephony providers edges trunkbasesettings list --autopaginate > trunkbasesettings.json

gc telephony providers edges trunks list --autopaginate > trunks.json

Edges and Edge groups:

gc telephony providers edges list --autopaginate > edges.json

gc telephony providers edges edgegroups list --autopaginate > edgegroups.json

Die Zertifizierungsstellen werden so erfasst:

gc telephony providers edges certificateauthorities list --autopaginate > certificate_authorities.json

Side-ID kann man der gezogenen Site-Liste entnehmen. Pro Site muss ein numberplan gezogen werden.

gc telephony providers edges outboundroutes list --autopaginate > outboundroutes.json

gc telephony providers edges sites numberplans list 471ba2a6-xxxx-418e-bd9c-23593485f8ba > DreieichTestsite.json

Phone base settings and phones

gc telephony providers edges phonebasesettings list --autopaginate > phonebasesettings.json

gc telephony providers edges phones list --autopaginate > phones.json

Roles
gc authorization roles list --autopaginate > roles.json

17 Groups und Nutzer
gc groups list --autopaginate > groups.json
gc users list --expand "groups" --autopaginate > users_groups.json 
gc users list --expand "authorization" --autopaginate > users_with_roles.json

19 Divisions
gc authorization divisions list --autopaginate > divisions.json

20 Wrapup Codes
gc routing wrapupcodes list --autopaginate > wrapupcodes.json

DIDs
gc telephony providers edges dids list --autopaginate > DID_list.json

23 oAuths
gc oauth clients list --autopaginate > oAuth_clients.json

24 Integrations
gc integrations list --autopaginate > integrations_list.json

25 Email
gc routing email domains list --autopaginate > emaildomains.json
Für jede darin enthaltene E-Mail-Domain:
gc routing email domains routes list cronbank.de --autopaginate > emailroutes_cronbank.de.json

26 Trigger
Gesicherte Trigger enthalten nur einen Verweis auf die Workflow-ID, was herzlich wenig bringt, wenn die Flows nach einem Totalausfall neu aufgebaut werden müssen. Entsprechend muss für jeden Trigger eine sinnvolle Discription verfasst werden, was die Aufgabe des Triggers ist und auf welchen Workflow sie namentlich verweist.
gc processautomation triggers list --autopaginate > triggers.json

Kampagnenliste:

gc outbound campaigns list --autopaginate > outbound_campaigns.json

Kampagnen-Regeln (Stand 26.9.25 leer):

gc outbound campaignrules list --autopaginate > outbound_campaginrules.json

Liste der Kontaktlisten:

gc outbound contactlists list --autopaginate > outbound_contactlists.json

è Einzelne aktuelle Kontaktlisten via UI runterladen. Dazu gehören auch die NoCall-Detections.

Regelsets:

gc outbound rulesets list --autopaginate > outbound_rulesets.json

Outbound-Einstellungen:

gc outbound settings get > outbound_settings.json

Hi @Christoph Domaschke,

Can you tell me a little more about what you mean when you say you do your backups via CLI? What are you backing up, how?

Hi Rodrigo,

usally I tend to use the API explorer to learn new functionality and mostly because I then can create a data action from what I learned. But for repeating jobs I really love to use CLI.

Because we can't use terraform I do my backups via CLI. Its so easy with CLI that everyone that reads my backup-manual can use it - just simply copy & paste the commands.

I find CLI pretty handy when creating new users. I have a set of CLI-commands that help me to do the job in half of the time I need manually.

If you've spent time working with Genesys Cloud APIs, you already understand more about the CLI than you might think.

I used to look at CLI commands and feel like they belonged in a different world. But once I started mapping them back to REST APIs, it clicked: it's the same conversation with the platform, just written differently.

So here's a simple way to think about it.

The REST API structure (the one most of us know):
METHOD /url-endpoint?query=params&expand=...

Example:
GET /api/v2/users?pageSize=25&expand=presence

In plain terms:
"Get me a list of users, limit it to 25, and include their presence information."

Now let's look at the CLI version of that same request.

The CLI structure:
gc <resource> <command> --flag value

Example:
gc users list --pageSize 25 --expand presence

Same request. Same outcome. Just a different way of asking.

Here's how the pieces map:

• METHOD (GET, POST, PUT, DELETE) → becomes the command (list, create, update, delete)

• Endpoint (/api/v2/users) → becomes the resource (users)

• Query params (?pageSize=25&expand=presence) → become flags (--pageSize 25 --expand presence)

Once you see this, the CLI stops feeling new. It's just a more direct way to work with the API.

A few flags you'll see all the time:

• --expand
  Ask for additional related data. Instead of making multiple calls, you bring more context into one response.

• --pageSize
  Control how many results come back. Useful when you're testing or trying to limit output.

• --pageNumber
  Move through paginated results. Same idea as API pagination, just cleaner to type.

• --id
  Target a specific object. Instead of filtering a list, you go straight to what you need.

• --name
  Often used when creating or filtering resources in a more human-readable way.

• --file
  Pass a JSON payload from a file. This is especially useful for create/update operations where typing everything inline would be painful.

The more you work with both, the more you realize:

The API asks through HTTP.
The CLI asks through commands.
But both are asking Genesys Cloud to do the exact same thing.

And sometimes, the CLI is just the faster way to say it. 

If you want to learn more about APIs in Genesys Cloud, do not forget to checkout the resources available at Genesys Education, specially our Workshop on Genesys CLI.

Curious to hear from others: do you tend to reach for APIs or the CLI first when working in Genesys Cloud - and why?

Awesome. I think I'm going to adopt it from you. I've also spent the afternoon working on a GC CLI / Archy hybrid to create .yaml and architect flow backups too.

I'm sure there is a more "correct" way of doing this (Terraform), but I never really got on with Terraform that much. Maybe I should look again.

Yes, i do all components on recurring basis. If you copy paste all commands into the command line in one stept it executes all of them automaticly.
For me this solution is "better than nothing" and I really hope not to rebuild the system one day with that backups. 

A cron job is a great idea, thanks for that!

This is something you run on a recurring basis, and backup all those each time? Or are you just backing up bits and pieces as you go?

Like before you delete a user you backup the users etc? 

Just interested to see how you are using it, it's a good idea and not something I had considered, but it's something that would be easy to implement. Could create a cron job to get a local backup of the platform (partly) each week.

Hi @James Dunn,

I do not backup all components via CLI, just that ones, that are not good do backup via UI. Here is my (german) list. Please use an AI-bot for translation:

Flow-Outcomes

gc flows outcomes list --autopaginate > 01_flow_outcomes.json

und die Milestones, die im Flow verwendet werden:

gc flows milestones list --autopaginate > 02_flow_milestones.json

Queues können nicht über das User-Interface (UI) exportiert werden. Das CLI (Command Line Interface) ist am besten geeignet:

gc routing queues list --autopaginate > queues.json

Liste der Prompts mit CLI gezogen werden:

gc architect prompts list --includeMediaUris true  --includeResources true --autopaginate > prompts.json

Skills and languages:

gc routing skills list --autopaginate > skills.json

gc routing languages list --autopaginate > languages.json

Shedules & shedule groups:

gc architect schedules list --autopaginate > schedules.json

gc architect schedulegroups list --autopaginate > schedulegroups.json

Emergency groups:
gc architect emergencygroups list --autopaginate > emergencygroups.json

Sites and locations:

gc telephony providers edges sites list --autopaginate > sites.json

gc locations list --autopaginate > locations.json

Trunks and base trunk settings:

gc telephony providers edges trunkbasesettings list --autopaginate > trunkbasesettings.json

gc telephony providers edges trunks list --autopaginate > trunks.json

Edges and Edge groups:

gc telephony providers edges list --autopaginate > edges.json

gc telephony providers edges edgegroups list --autopaginate > edgegroups.json

Die Zertifizierungsstellen werden so erfasst:

gc telephony providers edges certificateauthorities list --autopaginate > certificate_authorities.json

Side-ID kann man der gezogenen Site-Liste entnehmen. Pro Site muss ein numberplan gezogen werden.

gc telephony providers edges outboundroutes list --autopaginate > outboundroutes.json

gc telephony providers edges sites numberplans list 471ba2a6-xxxx-418e-bd9c-23593485f8ba > DreieichTestsite.json

Phone base settings and phones

gc telephony providers edges phonebasesettings list --autopaginate > phonebasesettings.json

gc telephony providers edges phones list --autopaginate > phones.json

Roles
gc authorization roles list --autopaginate > roles.json

17 Groups und Nutzer
gc groups list --autopaginate > groups.json
gc users list --expand "groups" --autopaginate > users_groups.json 
gc users list --expand "authorization" --autopaginate > users_with_roles.json

19 Divisions
gc authorization divisions list --autopaginate > divisions.json

20 Wrapup Codes
gc routing wrapupcodes list --autopaginate > wrapupcodes.json

DIDs
gc telephony providers edges dids list --autopaginate > DID_list.json

23 oAuths
gc oauth clients list --autopaginate > oAuth_clients.json

24 Integrations
gc integrations list --autopaginate > integrations_list.json

25 Email
gc routing email domains list --autopaginate > emaildomains.json
Für jede darin enthaltene E-Mail-Domain:
gc routing email domains routes list cronbank.de --autopaginate > emailroutes_cronbank.de.json

26 Trigger
Gesicherte Trigger enthalten nur einen Verweis auf die Workflow-ID, was herzlich wenig bringt, wenn die Flows nach einem Totalausfall neu aufgebaut werden müssen. Entsprechend muss für jeden Trigger eine sinnvolle Discription verfasst werden, was die Aufgabe des Triggers ist und auf welchen Workflow sie namentlich verweist.
gc processautomation triggers list --autopaginate > triggers.json

Kampagnenliste:

gc outbound campaigns list --autopaginate > outbound_campaigns.json

Kampagnen-Regeln (Stand 26.9.25 leer):

gc outbound campaignrules list --autopaginate > outbound_campaginrules.json

Liste der Kontaktlisten:

gc outbound contactlists list --autopaginate > outbound_contactlists.json

è Einzelne aktuelle Kontaktlisten via UI runterladen. Dazu gehören auch die NoCall-Detections.

Regelsets:

gc outbound rulesets list --autopaginate > outbound_rulesets.json

Outbound-Einstellungen:

gc outbound settings get > outbound_settings.json

Hi @Christoph Domaschke,

Can you tell me a little more about what you mean when you say you do your backups via CLI? What are you backing up, how?

Hi Rodrigo,

usally I tend to use the API explorer to learn new functionality and mostly because I then can create a data action from what I learned. But for repeating jobs I really love to use CLI.

Because we can't use terraform I do my backups via CLI. Its so easy with CLI that everyone that reads my backup-manual can use it - just simply copy & paste the commands.

I find CLI pretty handy when creating new users. I have a set of CLI-commands that help me to do the job in half of the time I need manually.

If you've spent time working with Genesys Cloud APIs, you already understand more about the CLI than you might think.

I used to look at CLI commands and feel like they belonged in a different world. But once I started mapping them back to REST APIs, it clicked: it's the same conversation with the platform, just written differently.

So here's a simple way to think about it.

The REST API structure (the one most of us know):
METHOD /url-endpoint?query=params&expand=...

Example:
GET /api/v2/users?pageSize=25&expand=presence

In plain terms:
"Get me a list of users, limit it to 25, and include their presence information."

Now let's look at the CLI version of that same request.

The CLI structure:
gc <resource> <command> --flag value

Example:
gc users list --pageSize 25 --expand presence

Same request. Same outcome. Just a different way of asking.

Here's how the pieces map:

• METHOD (GET, POST, PUT, DELETE) → becomes the command (list, create, update, delete)

• Endpoint (/api/v2/users) → becomes the resource (users)

• Query params (?pageSize=25&expand=presence) → become flags (--pageSize 25 --expand presence)

Once you see this, the CLI stops feeling new. It's just a more direct way to work with the API.

A few flags you'll see all the time:

• --expand
  Ask for additional related data. Instead of making multiple calls, you bring more context into one response.

• --pageSize
  Control how many results come back. Useful when you're testing or trying to limit output.

• --pageNumber
  Move through paginated results. Same idea as API pagination, just cleaner to type.

• --id
  Target a specific object. Instead of filtering a list, you go straight to what you need.

• --name
  Often used when creating or filtering resources in a more human-readable way.

• --file
  Pass a JSON payload from a file. This is especially useful for create/update operations where typing everything inline would be painful.

The more you work with both, the more you realize:

The API asks through HTTP.
The CLI asks through commands.
But both are asking Genesys Cloud to do the exact same thing.

And sometimes, the CLI is just the faster way to say it. 

If you want to learn more about APIs in Genesys Cloud, do not forget to checkout the resources available at Genesys Education, specially our Workshop on Genesys CLI.

Curious to hear from others: do you tend to reach for APIs or the CLI first when working in Genesys Cloud - and why?

Hi @James Dunn,

I do not backup all components via CLI, just that ones, that are not good do backup via UI. Here is my (german) list. Please use an AI-bot for translation:

Flow-Outcomes

gc flows outcomes list --autopaginate > 01_flow_outcomes.json

und die Milestones, die im Flow verwendet werden:

gc flows milestones list --autopaginate > 02_flow_milestones.json

Queues können nicht über das User-Interface (UI) exportiert werden. Das CLI (Command Line Interface) ist am besten geeignet:

gc routing queues list --autopaginate > queues.json

Liste der Prompts mit CLI gezogen werden:

gc architect prompts list --includeMediaUris true  --includeResources true --autopaginate > prompts.json

Skills and languages:

gc routing skills list --autopaginate > skills.json

gc routing languages list --autopaginate > languages.json

Shedules & shedule groups:

gc architect schedules list --autopaginate > schedules.json

gc architect schedulegroups list --autopaginate > schedulegroups.json

Emergency groups:
gc architect emergencygroups list --autopaginate > emergencygroups.json

Sites and locations:

gc telephony providers edges sites list --autopaginate > sites.json

gc locations list --autopaginate > locations.json

Trunks and base trunk settings:

gc telephony providers edges trunkbasesettings list --autopaginate > trunkbasesettings.json

gc telephony providers edges trunks list --autopaginate > trunks.json

Edges and Edge groups:

gc telephony providers edges list --autopaginate > edges.json

gc telephony providers edges edgegroups list --autopaginate > edgegroups.json

Die Zertifizierungsstellen werden so erfasst:

gc telephony providers edges certificateauthorities list --autopaginate > certificate_authorities.json

Side-ID kann man der gezogenen Site-Liste entnehmen. Pro Site muss ein numberplan gezogen werden.

gc telephony providers edges outboundroutes list --autopaginate > outboundroutes.json

gc telephony providers edges sites numberplans list 471ba2a6-xxxx-418e-bd9c-23593485f8ba > DreieichTestsite.json

Phone base settings and phones

gc telephony providers edges phonebasesettings list --autopaginate > phonebasesettings.json

gc telephony providers edges phones list --autopaginate > phones.json

Roles
gc authorization roles list --autopaginate > roles.json

17 Groups und Nutzer
gc groups list --autopaginate > groups.json
gc users list --expand "groups" --autopaginate > users_groups.json 
gc users list --expand "authorization" --autopaginate > users_with_roles.json

19 Divisions
gc authorization divisions list --autopaginate > divisions.json

20 Wrapup Codes
gc routing wrapupcodes list --autopaginate > wrapupcodes.json

DIDs
gc telephony providers edges dids list --autopaginate > DID_list.json

23 oAuths
gc oauth clients list --autopaginate > oAuth_clients.json

24 Integrations
gc integrations list --autopaginate > integrations_list.json

25 Email
gc routing email domains list --autopaginate > emaildomains.json
Für jede darin enthaltene E-Mail-Domain:
gc routing email domains routes list cronbank.de --autopaginate > emailroutes_cronbank.de.json

26 Trigger
Gesicherte Trigger enthalten nur einen Verweis auf die Workflow-ID, was herzlich wenig bringt, wenn die Flows nach einem Totalausfall neu aufgebaut werden müssen. Entsprechend muss für jeden Trigger eine sinnvolle Discription verfasst werden, was die Aufgabe des Triggers ist und auf welchen Workflow sie namentlich verweist.
gc processautomation triggers list --autopaginate > triggers.json

Kampagnenliste:

gc outbound campaigns list --autopaginate > outbound_campaigns.json

Kampagnen-Regeln (Stand 26.9.25 leer):

gc outbound campaignrules list --autopaginate > outbound_campaginrules.json

Liste der Kontaktlisten:

gc outbound contactlists list --autopaginate > outbound_contactlists.json

è Einzelne aktuelle Kontaktlisten via UI runterladen. Dazu gehören auch die NoCall-Detections.

Regelsets:

gc outbound rulesets list --autopaginate > outbound_rulesets.json

Outbound-Einstellungen:

gc outbound settings get > outbound_settings.json

Hi @Christoph Domaschke,

Can you tell me a little more about what you mean when you say you do your backups via CLI? What are you backing up, how?

Hi Rodrigo,

usally I tend to use the API explorer to learn new functionality and mostly because I then can create a data action from what I learned. But for repeating jobs I really love to use CLI.

Because we can't use terraform I do my backups via CLI. Its so easy with CLI that everyone that reads my backup-manual can use it - just simply copy & paste the commands.

I find CLI pretty handy when creating new users. I have a set of CLI-commands that help me to do the job in half of the time I need manually.

If you've spent time working with Genesys Cloud APIs, you already understand more about the CLI than you might think.

I used to look at CLI commands and feel like they belonged in a different world. But once I started mapping them back to REST APIs, it clicked: it's the same conversation with the platform, just written differently.

So here's a simple way to think about it.

The REST API structure (the one most of us know):
METHOD /url-endpoint?query=params&expand=...

Example:
GET /api/v2/users?pageSize=25&expand=presence

In plain terms:
"Get me a list of users, limit it to 25, and include their presence information."

Now let's look at the CLI version of that same request.

The CLI structure:
gc <resource> <command> --flag value

Example:
gc users list --pageSize 25 --expand presence

Same request. Same outcome. Just a different way of asking.

Here's how the pieces map:

• METHOD (GET, POST, PUT, DELETE) → becomes the command (list, create, update, delete)

• Endpoint (/api/v2/users) → becomes the resource (users)

• Query params (?pageSize=25&expand=presence) → become flags (--pageSize 25 --expand presence)

Once you see this, the CLI stops feeling new. It's just a more direct way to work with the API.

A few flags you'll see all the time:

• --expand
  Ask for additional related data. Instead of making multiple calls, you bring more context into one response.

• --pageSize
  Control how many results come back. Useful when you're testing or trying to limit output.

• --pageNumber
  Move through paginated results. Same idea as API pagination, just cleaner to type.

• --id
  Target a specific object. Instead of filtering a list, you go straight to what you need.

• --name
  Often used when creating or filtering resources in a more human-readable way.

• --file
  Pass a JSON payload from a file. This is especially useful for create/update operations where typing everything inline would be painful.

The more you work with both, the more you realize:

The API asks through HTTP.
The CLI asks through commands.
But both are asking Genesys Cloud to do the exact same thing.

And sometimes, the CLI is just the faster way to say it. 

If you want to learn more about APIs in Genesys Cloud, do not forget to checkout the resources available at Genesys Education, specially our Workshop on Genesys CLI.

Curious to hear from others: do you tend to reach for APIs or the CLI first when working in Genesys Cloud - and why?

Amazing info, Chirstoph! Just a quick comment --autopaginate can be summarize with -a , or, if needed, you may activate it by default by performing 

gc autopagination enable

Hi @James Dunn,

I do not backup all components via CLI, just that ones, that are not good do backup via UI. Here is my (german) list. Please use an AI-bot for translation:

Flow-Outcomes

gc flows outcomes list --autopaginate > 01_flow_outcomes.json

und die Milestones, die im Flow verwendet werden:

gc flows milestones list --autopaginate > 02_flow_milestones.json

Queues können nicht über das User-Interface (UI) exportiert werden. Das CLI (Command Line Interface) ist am besten geeignet:

gc routing queues list --autopaginate > queues.json

Liste der Prompts mit CLI gezogen werden:

gc architect prompts list --includeMediaUris true  --includeResources true --autopaginate > prompts.json

Skills and languages:

gc routing skills list --autopaginate > skills.json

gc routing languages list --autopaginate > languages.json

Shedules & shedule groups:

gc architect schedules list --autopaginate > schedules.json

gc architect schedulegroups list --autopaginate > schedulegroups.json

Emergency groups:
gc architect emergencygroups list --autopaginate > emergencygroups.json

Sites and locations:

gc telephony providers edges sites list --autopaginate > sites.json

gc locations list --autopaginate > locations.json

Trunks and base trunk settings:

gc telephony providers edges trunkbasesettings list --autopaginate > trunkbasesettings.json

gc telephony providers edges trunks list --autopaginate > trunks.json

Edges and Edge groups:

gc telephony providers edges list --autopaginate > edges.json

gc telephony providers edges edgegroups list --autopaginate > edgegroups.json

Die Zertifizierungsstellen werden so erfasst:

gc telephony providers edges certificateauthorities list --autopaginate > certificate_authorities.json

Side-ID kann man der gezogenen Site-Liste entnehmen. Pro Site muss ein numberplan gezogen werden.

gc telephony providers edges outboundroutes list --autopaginate > outboundroutes.json

gc telephony providers edges sites numberplans list 471ba2a6-xxxx-418e-bd9c-23593485f8ba > DreieichTestsite.json

Phone base settings and phones

gc telephony providers edges phonebasesettings list --autopaginate > phonebasesettings.json

gc telephony providers edges phones list --autopaginate > phones.json

Roles
gc authorization roles list --autopaginate > roles.json

17 Groups und Nutzer
gc groups list --autopaginate > groups.json
gc users list --expand "groups" --autopaginate > users_groups.json 
gc users list --expand "authorization" --autopaginate > users_with_roles.json

19 Divisions
gc authorization divisions list --autopaginate > divisions.json

20 Wrapup Codes
gc routing wrapupcodes list --autopaginate > wrapupcodes.json

DIDs
gc telephony providers edges dids list --autopaginate > DID_list.json

23 oAuths
gc oauth clients list --autopaginate > oAuth_clients.json

24 Integrations
gc integrations list --autopaginate > integrations_list.json

25 Email
gc routing email domains list --autopaginate > emaildomains.json
Für jede darin enthaltene E-Mail-Domain:
gc routing email domains routes list cronbank.de --autopaginate > emailroutes_cronbank.de.json

26 Trigger
Gesicherte Trigger enthalten nur einen Verweis auf die Workflow-ID, was herzlich wenig bringt, wenn die Flows nach einem Totalausfall neu aufgebaut werden müssen. Entsprechend muss für jeden Trigger eine sinnvolle Discription verfasst werden, was die Aufgabe des Triggers ist und auf welchen Workflow sie namentlich verweist.
gc processautomation triggers list --autopaginate > triggers.json

Kampagnenliste:

gc outbound campaigns list --autopaginate > outbound_campaigns.json

Kampagnen-Regeln (Stand 26.9.25 leer):

gc outbound campaignrules list --autopaginate > outbound_campaginrules.json

Liste der Kontaktlisten:

gc outbound contactlists list --autopaginate > outbound_contactlists.json

è Einzelne aktuelle Kontaktlisten via UI runterladen. Dazu gehören auch die NoCall-Detections.

Regelsets:

gc outbound rulesets list --autopaginate > outbound_rulesets.json

Outbound-Einstellungen:

gc outbound settings get > outbound_settings.json

Hi @Christoph Domaschke,

Can you tell me a little more about what you mean when you say you do your backups via CLI? What are you backing up, how?

Hi Rodrigo,

usally I tend to use the API explorer to learn new functionality and mostly because I then can create a data action from what I learned. But for repeating jobs I really love to use CLI.

Because we can't use terraform I do my backups via CLI. Its so easy with CLI that everyone that reads my backup-manual can use it - just simply copy & paste the commands.

I find CLI pretty handy when creating new users. I have a set of CLI-commands that help me to do the job in half of the time I need manually.

If you've spent time working with Genesys Cloud APIs, you already understand more about the CLI than you might think.

I used to look at CLI commands and feel like they belonged in a different world. But once I started mapping them back to REST APIs, it clicked: it's the same conversation with the platform, just written differently.

So here's a simple way to think about it.

The REST API structure (the one most of us know):
METHOD /url-endpoint?query=params&expand=...

Example:
GET /api/v2/users?pageSize=25&expand=presence

In plain terms:
"Get me a list of users, limit it to 25, and include their presence information."

Now let's look at the CLI version of that same request.

The CLI structure:
gc <resource> <command> --flag value

Example:
gc users list --pageSize 25 --expand presence

Same request. Same outcome. Just a different way of asking.

Here's how the pieces map:

• METHOD (GET, POST, PUT, DELETE) → becomes the command (list, create, update, delete)

• Endpoint (/api/v2/users) → becomes the resource (users)

• Query params (?pageSize=25&expand=presence) → become flags (--pageSize 25 --expand presence)

Once you see this, the CLI stops feeling new. It's just a more direct way to work with the API.

A few flags you'll see all the time:

• --expand
  Ask for additional related data. Instead of making multiple calls, you bring more context into one response.

• --pageSize
  Control how many results come back. Useful when you're testing or trying to limit output.

• --pageNumber
  Move through paginated results. Same idea as API pagination, just cleaner to type.

• --id
  Target a specific object. Instead of filtering a list, you go straight to what you need.

• --name
  Often used when creating or filtering resources in a more human-readable way.

• --file
  Pass a JSON payload from a file. This is especially useful for create/update operations where typing everything inline would be painful.

The more you work with both, the more you realize:

The API asks through HTTP.
The CLI asks through commands.
But both are asking Genesys Cloud to do the exact same thing.

And sometimes, the CLI is just the faster way to say it. 

If you want to learn more about APIs in Genesys Cloud, do not forget to checkout the resources available at Genesys Education, specially our Workshop on Genesys CLI.

Curious to hear from others: do you tend to reach for APIs or the CLI first when working in Genesys Cloud - and why?