{"id":2781,"date":"2026-06-01T10:39:31","date_gmt":"2026-06-01T10:39:31","guid":{"rendered":"https:\/\/sawaryn.com\/uslugi\/creating-rules-and-regulations\/"},"modified":"2026-07-14T17:03:16","modified_gmt":"2026-07-14T17:03:16","slug":"creating-rules-and-regulations","status":"publish","type":"service","link":"https:\/\/sawaryn.com\/en\/uslugi\/creating-rules-and-regulations\/","title":{"rendered":"Creating Rules and Regulations"},"excerpt":{"rendered":"<p>We design the operating principles for games, platforms, stores, events, and communities so that they support the product\u2019s launch, monetization, and continued development-without any disconnect between documentation, UX, payments, and actual user behavior.<\/p>\n","protected":false},"featured_media":0,"template":"","meta":{"_acf_changed":false},"specialization":[1209],"practice_area":[],"class_list":["post-2781","service","type-service","status-publish","hentry","specialization-gaming-game-development"],"acf":{"short_description":"We create the operating rules for games, platforms, stores, events and communities so they support launch, monetisation and further product development - without a mismatch between documents, UX, payments and real user behaviour.","full_description":"<strong>Terms of service that keep pace with the gaming product<\/strong>\n\nWe create the operating rules for games, platforms, stores, events and communities so they support launch, monetisation and further product development - without a mismatch between documents, UX, payments and real user behaviour.\n\nProduct dashboard view: user-journey map, payment modules, community rules, platform requirements and legal documents joined into one logical system.\n<h2>CLIENT PROBLEM<\/h2>\n<strong>Terms of service cannot be the last file before launch<\/strong>\n\nWhen a game, platform or store is almost ready, the rules are often written under time pressure. The team needs \u201csomething to publish\u201d, but the product has already grown: it has microtransactions, user accounts, a marketplace, Discord, beta tests, UGC, events or several distribution channels.\n\n\u201cGood terms of service never describe an abstract product. They organise how the product actually works: what the user pays for, what they may and may not, and how the team responds when a dispute arises.\u201d\n\nTerms copied from another product will not hold that logic. They may not fit the game mechanics, payment model, complaint process, platform requirements or moderation rules. Then the document does not help the team - it only adds another place where ambiguity appears.\n<h2>MOST COMMON PROBLEMS \/ CHALLENGES<\/h2>\n<strong>The terms of service fail to describe the real product<\/strong>\n\nThe product works differently from the documents. Mechanics, payments, accounts, content access and the user relationship are spelled out in the game, but not in the rules. That makes disputes, complaints and post-launch changes harder to handle.\n\nWe map the product: mechanics, user journey, revenue sources, distribution channels, account rules and risk points. Only on that basis we draft the terms of service.\n\n<strong>Business benefit:<\/strong> The team has rules that fit the product, not a document detached from day-to-day work.\n\n<strong>Risk of inaction:<\/strong> The further the product develops, the more exceptions, gaps and decisions made \u201cby feel\u201d appear.\n\n<strong>Monetisation moves faster than the purchase rules<\/strong>\n\nMicrotransactions, DLC, subscriptions, in-game currencies or access to content need clear rules: what the user buys, when they can cancel, how a complaint works and what happens if an account is blocked.\n\nWe design rules for in-game purchases, digital content, subscriptions, promotions and complaints. We link them to in-product communication and the user support process.\n\n<strong>Business benefit:<\/strong> The revenue model has legal and operational backing, and the team never improvises in payment disputes.\n\n<strong>Risk of inaction:<\/strong> Unclear rules increase the risk of complaints, chargebacks, conflicts with users and inconsistent handling of tickets.\n\n<strong>The distribution platform has its own requirements<\/strong>\n\nSteam, Epic Games, GOG and other channels are not only a place to publish. They have their own standards, limits and expectations for the product, content, sales and communication with the user.\n\nWe adapt the terms of service and related documents to platform requirements and to how the game will be distributed.\n\n<strong>Business benefit:<\/strong> A launch or update never stops on formalities that could have been anticipated earlier.\n\n<strong>Risk of inaction:<\/strong> The team may go to release with documents that fail to match the sales channel rules or fail to cover key user scenarios.\n\n<strong>The community grows, but the rules are scattered<\/strong>\n\nForum, Discord, UGC, reports, bans, moderation, contests, beta tests - each of these areas needs clear rules. Without them the community can become a source of tension, escalation and reputational risk.\n\nWe create community, moderation, user-generated content, event and test rules. We show how to apply them in practice.\n\n<strong>Business benefit:<\/strong> Community, support and product share one point of reference.\n\n<strong>Risk of inaction:<\/strong> Moderation decisions become harder to defend, and conflicts with users more often leave the channels controlled by the studio.\n\n<strong>The documents speak different languages<\/strong>\n\nThe terms of service, privacy policy, FAQ, purchase screen, marketing messages and user panel should guide the user with the same logic. When each element says something different, the risk of misunderstanding grows.\n\nWe organise the relationship between the terms of service, privacy policy, complaints, sales communication and product UX.\n\n<strong>Business benefit:<\/strong> The user gets a consistent message, and the team never has to explain discrepancies between the documents and the product.\n\n<strong>Risk of inaction:<\/strong> Inconsistency may return as a complaint, a dispute, a platform issue or a costly fix after go-live.\n<h2>HOW OUR SOLUTION WORKS<\/h2>\n<strong>Product rules, not a document for formality\u2019s sake<\/strong>\n\nWe never start from a template. First we check how the product works, where revenue is created, how the user makes decisions and where the team needs clear rules. Then we turn that into terms of service and documents that can be implemented in the product, processes and communication.\n\n<strong>Product and operating-model analysis<\/strong>\n<ul>\n \t<li>game or platform mechanics,<\/li>\n \t<li>user accounts and access levels,<\/li>\n \t<li>payments, subscriptions, DLC, currencies or digital content,<\/li>\n \t<li>distribution channels,<\/li>\n \t<li>user journey,<\/li>\n \t<li>dispute points and complaint scenarios.<\/li>\n<\/ul>\nA map of the areas that must be described in the terms of service and related documents.\n\n<strong>Audit of existing documents<\/strong>\n<ul>\n \t<li>game or platform terms of service,<\/li>\n \t<li>store terms,<\/li>\n \t<li>privacy policy,<\/li>\n \t<li>complaint rules,<\/li>\n \t<li>sales messages,<\/li>\n \t<li>FAQ and in-product content,<\/li>\n \t<li>community or moderation rules.<\/li>\n<\/ul>\nA list of gaps, inconsistencies and decisions that need to be organised before go-live or an update.\n\n<strong>Terms-of-service logic design<\/strong>\n<ul>\n \t<li>who uses the product and on what terms,<\/li>\n \t<li>what the user pays for,<\/li>\n \t<li>when access may be restricted,<\/li>\n \t<li>how a complaint works,<\/li>\n \t<li>what content the user may publish,<\/li>\n \t<li>how the studio may respond to abuse,<\/li>\n \t<li>how the rules change as the product develops.<\/li>\n<\/ul>\nA product-rules structure that shows which documents are needed and how they should work together.\n\n<strong>Drafting terms of service and related documents<\/strong>\n<ul>\n \t<li>game terms of service,<\/li>\n \t<li>platform terms of service,<\/li>\n \t<li>user account terms,<\/li>\n \t<li>in-game purchase rules,<\/li>\n \t<li>subscription and digital-content access rules,<\/li>\n \t<li>event, contest or beta-test terms.<\/li>\n<\/ul>\nReady documents matched to the product, sales model and user journey.\n\n<strong>Community and moderation rules<\/strong>\n<ul>\n \t<li>user conduct rules,<\/li>\n \t<li>user-generated content,<\/li>\n \t<li>account block, warning and restriction rules,<\/li>\n \t<li>moderation of a forum, Discord or other channels,<\/li>\n \t<li>escalations and violations.<\/li>\n<\/ul>\nRules that help run the community without reinventing every decision from scratch.\n\n<strong>Alignment with platforms and distribution channels<\/strong>\n<ul>\n \t<li>sales-platform requirements,<\/li>\n \t<li>the relationship between product terms and platform rules,<\/li>\n \t<li>publishing a game or update,<\/li>\n \t<li>promotions, content access, limits and user messages.<\/li>\n<\/ul>\nTerms of service prepared with distribution in mind, not only the studio website.\n\n<strong>Implementation support<\/strong>\n<ul>\n \t<li>recommendations for UX and purchase screens,<\/li>\n \t<li>support touchpoints,<\/li>\n \t<li>messages for users,<\/li>\n \t<li>marking places where the rules must be visible,<\/li>\n \t<li>walking the documents through with the product or operations team.<\/li>\n<\/ul>\nTerms of service ready to use in the product, customer support and communication with players.\n<h2>WHO THIS SERVICE IS FOR<\/h2>\n<strong>For teams that need clear rules before launch, a model change or product scaling<\/strong>\n\nProduct Manager \/ Producer - when terms of service must be synchronised with game mechanics, payments, UX and the release plan.\n\nHead of Legal \/ Compliance Manager - when documents must cover the product, platforms, users, complaints and regulatory risks without drifting away from how the team works.\n\nCEO \/ Founder \/ Management board member - when terms of service should limit risk, support monetisation and give predictability before launch, an update or entry into new markets.\n<h2>STAGES OF WORK<\/h2>\n<strong>A process that keeps the law close to the product<\/strong>\n\nCooperation is set up to move quickly from a product picture to rules, documents and implementation. Without multiplying meetings. Without writing in a vacuum. Without shifting conceptual legal work onto the team.\n\n<strong>Diagnosis and product mapping<\/strong>\n\nWe talk with the team about mechanics, users, payments, distribution, community and planned changes. We check where the rules will really be used: in the game, the store, support, moderation, marketing and the relationship with the platform.\n\n<strong>What the client gains:<\/strong> A clear picture of the areas that need terms of service or a correction of existing rules.\n\n<strong>Rules design<\/strong>\n\nWe design the document logic: what the main terms should govern, what needs separate rules, and where provisions are needed for payments, accounts, community, user content or events.\n\n<strong>What the client gains:<\/strong> Decisions that organise the product before documents are written.\n\n<strong>Document drafting<\/strong>\n\nWe draft the terms of service and related documents. We keep the language clear for the user and useful for the team that will apply the rules in practice.\n\n<strong>What the client gains:<\/strong> A set of documents matched to the product, revenue model and distribution method.\n\n<strong>Implementation and operational alignment<\/strong>\n\nWe indicate where the documents should appear in the product, which messages need consistency, and how to translate the rules into processes: complaints, support, moderation, account blocks, updates and model changes.\n\n<strong>What the client gains:<\/strong> Terms of service that can be implemented in how the team works, not only published in the website footer.","icon":"","order_within_specialization":0,"flexible_content":[{"acf_fc_layout":"hero","section_header":{"section_header":{"eyebrow":"","heading":"Terms of service that keep pace with the gaming product","heading_highlight_mode":"split","heading_split":{"small_part_text":"","strong_part_text":"","":null,"small_part_size":"h2","strong_part_size":"hero2","tag":"h2","style":"inherit","alignment":"inherit"},"description":"We create the operating rules for games, platforms, stores, events and communities so they support launch, monetisation and further product development - without a mismatch between documents, UX, payments and real user behaviour.","":null,"heading_tag":"h1","heading_style":"hero","alignment":"left"}},"actions":{"button_cluster":{"intro":"","buttons":[{"button":{"link":{"title":"Book a call about your terms and conditions","url":"#contact","target":""},"variant":"primary","icon":"arrow","icon_size":"inherit","size":"default","aria_label":""}}],"alignment":"left"}},"media":{"media":{"image":"","mobile_image":"","object_position":"center","object_position_custom":""}},"section_meta":{"anchor_id":"","is_enabled":true},"variant":"split","mobile_body_card":false},{"acf_fc_layout":"person_cta","person":[2695],"section_header":{"section_header":{"eyebrow":"","heading":"Terms of service cannot be the last file before launch","heading_highlight_mode":"none","heading_split":{"small_part_text":"","strong_part_text":"","":null,"small_part_size":"","strong_part_size":"","tag":"h2","style":"inherit","alignment":"inherit"},"description":"When a game, platform or store is almost ready, the rules are often written under time pressure. The team needs \u201csomething to publish\u201d, but the product has already grown: it has microtransactions, user accounts, a marketplace, Discord, beta tests, UGC, events or several distribution channels.\n\n\u201cGood terms of service never describe an abstract product. They organise how the product actually works: what the user pays for, what they may and may not, and how the team responds when a dispute arises.\u201d\n\nTerms copied from another product will not hold that logic. They may not fit the game mechanics, payment model, complaint process, platform requirements or moderation rules. Then the document does not help the team - it only adds another place where ambiguity appears.","":null,"heading_tag":"h2","heading_style":"section","alignment":"left"}},"carousel_settings":{"carousel_settings":{"autoplay_mode":"default","autoplay_delay":6.5}},"actions":{"button_cluster":{"intro":"","buttons":null,"alignment":"left"}}},{"acf_fc_layout":"expandable_box","section_header":{"section_header":{"eyebrow":"Most common problems \/ challenges","heading":"The most common problems we solve","heading_highlight_mode":"none","heading_split":{"small_part_text":"","strong_part_text":"","":null,"small_part_size":"","strong_part_size":"","tag":"h2","style":"inherit","alignment":"inherit"},"description":"","":null,"heading_tag":"h2","heading_style":"section","alignment":"center"}},"items":[{"problem_title":"The terms of service fail to describe the real product","teaser_description":"The product works differently from the documents. Mechanics, payments, accounts, content access and the user relationship are spelled out in the game, but not in the rules. That makes disputes, complaints and post-launch changes harder to handle.","solution_title":"","solution_description":"<p>We map the product: mechanics, user journey, revenue sources, distribution channels, account rules and risk points. Only on that basis we draft the terms of service.<\/p>\n\n<p>The team has rules that fit the product, not a document detached from day-to-day work.<\/p>\n\n<p>The further the product develops, the more exceptions, gaps and decisions made \u201cby feel&quot; appear.<\/p>","icon":"","accent":"pink","open":false},{"problem_title":"Monetisation moves faster than the purchase rules","teaser_description":"Microtransactions, DLC, subscriptions, in-game currencies or access to content need clear rules: what the user buys, when they can cancel, how a complaint works and what happens if an account is blocked.","solution_title":"","solution_description":"<p>We design rules for in-game purchases, digital content, subscriptions, promotions and complaints. We link them to in-product communication and the user support process.<\/p>\n\n<p>The revenue model has legal and operational backing, and the team does not improvise in payment disputes.<\/p>\n\n<p>Unclear rules increase the risk of complaints, chargebacks, conflicts with users and inconsistent handling of tickets.<\/p>","icon":"","accent":"violet","open":false},{"problem_title":"The distribution platform has its own requirements","teaser_description":"Steam, Epic Games, GOG and other channels are not only a place to publish. They have their own standards, limits and expectations for the product, content, sales and communication with the user.","solution_title":"","solution_description":"<p>We adapt the terms of service and related documents to platform requirements and to how the game will be distributed.<\/p>\n\n<p>A launch or update does not stop on formalities that could have been anticipated earlier.<\/p>\n\n<p>The team may go to release with documents that fail to match the sales channel rules or fail to cover key user scenarios.<\/p>","icon":"","accent":"blue","open":false},{"problem_title":"The community grows, but the rules are scattered","teaser_description":"Forum, Discord, UGC, reports, bans, moderation, contests, beta tests - each of these areas needs clear rules. Without them the community can become a source of tension, escalation and reputational risk.","solution_title":"","solution_description":"<p>We create community, moderation, user-generated content, event and test rules. We show how to apply them in practice.<\/p>\n\n<p>Community, support and product share one point of reference.<\/p>\n\n<p>Moderation decisions become harder to defend, and conflicts with users more often leave the channels controlled by the studio.<\/p>","icon":"","accent":"orange","open":false},{"problem_title":"The documents speak different languages","teaser_description":"The terms of service, privacy policy, FAQ, purchase screen, marketing messages and user panel should guide the user with the same logic. When each element says something different, the risk of misunderstanding grows.","solution_title":"","solution_description":"<p>We organise the relationship between the terms of service, privacy policy, complaints, sales communication and product UX.<\/p>\n\n<p>The user gets a consistent message, and the team does not have to explain discrepancies between the documents and the product.<\/p>\n\n<p>Inconsistency may return as a complaint, a dispute, a platform issue or a costly fix after go-live.<\/p>","icon":"","accent":"pink","open":false}],"section_meta":{"anchor_id":"","is_enabled":true}},{"acf_fc_layout":"box_variants","variant":"process-detail","section_header":{"section_header":{"eyebrow":"Our solution","heading":"What exactly you get","heading_highlight_mode":"none","heading_split":{"small_part_text":"","strong_part_text":"","":null,"small_part_size":"","strong_part_size":"","tag":"h2","style":"inherit","alignment":"inherit"},"description":"","":null,"heading_tag":"h2","heading_style":"section","alignment":"center"}},"items":[{"title":"Product rules, not a document for formality\u2019s sake","description":"","body":"We never start from a template. First we check how the product works, where revenue is created, how the user makes decisions and where the team needs clear rules. Then we turn that into terms of service and documents that can be implemented in the product, processes and communication.","tags":"","count":"","accent":"pink","icon":""},{"title":"Product and operating-model analysis","description":"","body":"<ul>\n \t<li>game or platform mechanics,<\/li>\n \t<li>user accounts and access levels,<\/li>\n \t<li>payments, subscriptions, DLC, currencies or digital content,<\/li>\n \t<li>distribution channels,<\/li>\n \t<li>user journey,<\/li>\n \t<li>dispute points and complaint scenarios.<\/li>\n<\/ul>\nA map of the areas that must be described in the terms of service and related documents.","tags":"","count":"","accent":"violet","icon":""},{"title":"Audit of existing documents","description":"","body":"<ul>\n \t<li>game or platform terms of service,<\/li>\n \t<li>store terms,<\/li>\n \t<li>privacy policy,<\/li>\n \t<li>complaint rules,<\/li>\n \t<li>sales messages,<\/li>\n \t<li>FAQ and in-product content,<\/li>\n \t<li>community or moderation rules.<\/li>\n<\/ul>\nA list of gaps, inconsistencies and decisions that need to be organised before go-live or an update.","tags":"","count":"","accent":"pink","icon":""},{"title":"Terms-of-service logic design","description":"","body":"<ul>\n \t<li>who uses the product and on what terms,<\/li>\n \t<li>what the user pays for,<\/li>\n \t<li>when access may be restricted,<\/li>\n \t<li>how a complaint works,<\/li>\n \t<li>what content the user may publish,<\/li>\n \t<li>how the studio may respond to abuse,<\/li>\n \t<li>how the rules change as the product develops.<\/li>\n<\/ul>\nA product-rules structure that shows which documents are needed and how they should work together.","tags":"","count":"","accent":"orange","icon":""},{"title":"Drafting terms of service and related documents","description":"","body":"<ul>\n \t<li>game terms of service,<\/li>\n \t<li>platform terms of service,<\/li>\n \t<li>user account terms,<\/li>\n \t<li>store terms,<\/li>\n \t<li>in-game purchase rules,<\/li>\n \t<li>subscription and digital-content access rules,<\/li>\n \t<li>event, contest or beta-test terms.<\/li>\n<\/ul>\nReady documents matched to the product, sales model and user journey.","tags":"","count":"","accent":"pink","icon":""},{"title":"Community and moderation rules","description":"","body":"<ul>\n \t<li>user conduct rules,<\/li>\n \t<li>user-generated content,<\/li>\n \t<li>account block, warning and restriction rules,<\/li>\n \t<li>moderation of a forum, Discord or other channels,<\/li>\n \t<li>escalations and violations.<\/li>\n<\/ul>\nRules that help run the community without reinventing every decision from scratch.","tags":"","count":"","accent":"violet","icon":""},{"title":"Alignment with platforms and distribution channels","description":"","body":"<ul>\n \t<li>sales-platform requirements,<\/li>\n \t<li>the relationship between product terms and platform rules,<\/li>\n \t<li>publishing a game or update,<\/li>\n \t<li>promotions, content access, limits and user messages.<\/li>\n<\/ul>\nTerms of service prepared with distribution in mind, not only the studio website.","tags":"","count":"","accent":"blue","icon":""}],"footer_heading":"","footer_tags":"","actions":{"button_cluster":{"intro":"","buttons":null,"alignment":"left"}},"section_meta":{"anchor_id":"","is_enabled":true}},{"acf_fc_layout":"box_variants","variant":"box-point","section_header":{"section_header":{"eyebrow":"Who this service is for","heading":"Who this service is for","heading_highlight_mode":"none","heading_split":{"small_part_text":"","strong_part_text":"","":null,"small_part_size":"","strong_part_size":"","tag":"h2","style":"inherit","alignment":"inherit"},"description":"","":null,"heading_tag":"h2","heading_style":"section","alignment":"center"}},"items":[{"title":"For teams that need clear rules before launch, a model change or product scaling","description":"","body":"","tags":"","count":"","accent":"pink","icon":""},{"title":"Product Manager \/ Producer","description":"","body":"when terms of service must be synchronised with game mechanics, payments, UX and the release plan.","tags":"","count":"","accent":"violet","icon":""},{"title":"Head of Legal \/ Compliance Manager","description":"","body":"when documents must cover the product, platforms, users, complaints and regulatory risks without drifting away from how the team works.","tags":"","count":"","accent":"blue","icon":""}],"footer_heading":"","footer_tags":"","actions":{"button_cluster":{"intro":"","buttons":null,"alignment":"left"}},"section_meta":{"anchor_id":"","is_enabled":true}},{"acf_fc_layout":"cooperation_process","section_header":{"section_header":{"eyebrow":"Stages of work","heading":"How cooperation looks","heading_highlight_mode":"none","heading_split":{"small_part_text":"","strong_part_text":"","":null,"small_part_size":"","strong_part_size":"","tag":"h2","style":"inherit","alignment":"inherit"},"description":"","":null,"heading_tag":"h2","heading_style":"section","alignment":"center"}},"steps":[{"title":"Product assessment and mapping","description":"We discuss the mechanics, users, payments, distribution, community and planned changes with the team. We check where the rules will be used in practice: in the game, store, support, moderation, marketing and platform relationships.","accent":"pink"},{"title":"Designing the rules","description":"We structure the documents: what the main terms and conditions should cover, what requires separate rules, and where provisions are needed for payments, accounts, communities, user-generated content or events.","accent":"violet"},{"title":"Document preparation","description":"We draft terms and related documents. We make sure the language is clear to users and useful to the team that will apply the rules in practice.","accent":"blue"},{"title":"Implementation and operational alignment","description":"We identify where documents should appear in the product, which messages need to be consistent and how the rules should translate into processes for complaints, support, moderation, account blocks, updates and changes to the model.","accent":"orange"}],"cta_text":"Book a conversation about your terms and conditions.","actions":{"button_cluster":{"intro":"","buttons":[{"button":{"link":{"title":"Book a call about your terms and conditions","url":"#contact","target":""},"variant":"primary","icon":"arrow","icon_size":"inherit","size":"default","aria_label":""}}],"alignment":"left"}},"section_meta":{"anchor_id":"","is_enabled":true}},{"acf_fc_layout":"contact","section_header":{"section_header":{"eyebrow":"Write to us","heading":"Set the product rules before complaints, platforms or the community act for you","heading_highlight_mode":"none","heading_split":{"small_part_text":"","strong_part_text":"","":null,"small_part_size":"","strong_part_size":"","tag":"h2","style":"inherit","alignment":"inherit"},"description":"Terms of service work best when they are created before launch, payment go-live, community growth or entry into a new distribution channel. Then they can organise decisions, not only repair the aftermath.\n\nIn the form briefly describe: product type, stage of work, monetisation model, distribution channels and whether you already have existing terms. We will come back with a proposed next step.","":null,"heading_tag":"h2","heading_style":"section","alignment":"center"}},"person":2695,"person_eyebrow":"","person_body":"","response_title":"","response_body":"","form":{"cf7_form":"","name_label":"Imi\u0119 lub nazwa podmiotu","name_placeholder":"Wpisz swoje dane","phone_label":"Telefon","phone_placeholder":"+48 000 000 000","email_label":"E-mail","email_placeholder":"twoj@email.pl","message_label":"Napisz, czego potrzebujesz","message_placeholder":"Opisz kr\u00f3tko sytuacj\u0119, etap rozm\u00f3w i termin decyzji.","privacy_text":"O\u015bwiadczam, \u017ce podane dane kontaktowe mog\u0105 zosta\u0107 wykorzystane do odpowiedzi na moje zg\u0142oszenie.","newsletter_text":"","button_label":"Porozmawiajmy o regulaminach dla Twojego produktu"},"background":"","section_meta":{"anchor_id":"","is_enabled":true}}]},"_links":{"self":[{"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/service\/2781","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/service"}],"about":[{"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/types\/service"}],"version-history":[{"count":0,"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/service\/2781\/revisions"}],"wp:attachment":[{"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/media?parent=2781"}],"wp:term":[{"taxonomy":"specialization","embeddable":true,"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/specialization?post=2781"},{"taxonomy":"practice_area","embeddable":true,"href":"https:\/\/sawaryn.com\/en\/wp-json\/wp\/v2\/practice_area?post=2781"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}