{"id":1295,"date":"2025-11-04T15:04:08","date_gmt":"2025-11-04T12:04:08","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/kvkk-and-gdpr-compliant-hosting-without-the-headache-how-i-handle-data-localisation-logs-and-deletion-in-real-life\/"},"modified":"2025-11-04T15:04:08","modified_gmt":"2025-11-04T12:04:08","slug":"kvkk-and-gdpr-compliant-hosting-without-the-headache-how-i-handle-data-localisation-logs-and-deletion-in-real-life","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/kvkk-and-gdpr-compliant-hosting-without-the-headache-how-i-handle-data-localisation-logs-and-deletion-in-real-life\/","title":{"rendered":"KVKK and GDPR-Compliant Hosting, Without the Headache: How I Handle Data Localisation, Logs, and Deletion in Real Life"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>So there I was, coffee cooling on the desk, staring at a ticket from a client who\u2019d just landed their first big enterprise deal. \u201cWe need to be KVKK and GDPR compliant by next month. Can our hosting handle it?\u201d I could hear the mix of excitement and panic in their voice. If you\u2019ve ever been in that spot\u2014where legal letters meet server dashboards\u2014you know the feeling. You\u2019re wondering where your data actually lives, whether your logs are storing too much, and how on earth you delete data that\u2019s already buried in backups. It can feel like trying to organize a cluttered garage while the neighbors are watching.<\/p>\n<p>Here\u2019s the thing: compliance isn\u2019t about chasing obscure checkboxes. It\u2019s about building a hosting setup that respects people\u2019s data and has predictable rules for how you store, monitor, and clean things up. In this post, I\u2019ll walk you through how I approach KVKK and GDPR in hosting, with a focus on three practical pillars: <strong>data localisation<\/strong>, <strong>logging<\/strong>, and <strong>deletion policies<\/strong>. I\u2019ll share the way I explain it to clients, the shortcuts that save time, and the little gotchas that can trip you up. No stiff legalese, just what works in the real world.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#What_KVKK_and_GDPR_Actually_Expect_from_Your_Hosting\"><span class=\"toc_number toc_depth_1\">1<\/span> What KVKK and GDPR Actually Expect from Your Hosting<\/a><\/li><li><a href=\"#Data_Localisation_Where_Your_Data_Sleeps_Matters\"><span class=\"toc_number toc_depth_1\">2<\/span> Data Localisation: Where Your Data Sleeps Matters<\/a><ul><li><a href=\"#How_I_choose_regions_in_practice\"><span class=\"toc_number toc_depth_2\">2.1<\/span> How I choose regions in practice<\/a><\/li><\/ul><\/li><li><a href=\"#Privacy-Friendly_Logging_Keep_the_Lights_On_Without_Storing_the_Keys\"><span class=\"toc_number toc_depth_1\">3<\/span> Privacy-Friendly Logging: Keep the Lights On Without Storing the Keys<\/a><ul><li><a href=\"#Web_database_and_security_toolswhat_I_keep_in_mind\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Web, database, and security tools\u2014what I keep in mind<\/a><\/li><\/ul><\/li><li><a href=\"#Deletion_and_Retention_Policies_Making_the_Right_to_Be_Forgotten_Real\"><span class=\"toc_number toc_depth_1\">4<\/span> Deletion and Retention Policies: Making the Right to Be Forgotten Real<\/a><ul><li><a href=\"#Handling_special_cases_without_losing_your_mind\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Handling special cases without losing your mind<\/a><\/li><\/ul><\/li><li><a href=\"#Proving_Compliance_DPIAs_Audits_and_the_Paper_Trail_That_Saves_Time\"><span class=\"toc_number toc_depth_1\">5<\/span> Proving Compliance: DPIAs, Audits, and the Paper Trail That Saves Time<\/a><\/li><li><a href=\"#Practical_Hosting_Setups_I_Like_for_Compliance\"><span class=\"toc_number toc_depth_1\">6<\/span> Practical Hosting Setups I Like for Compliance<\/a><ul><li><a href=\"#A_note_on_vendor_choices_without_naming_names\"><span class=\"toc_number toc_depth_2\">6.1<\/span> A note on vendor choices without naming names<\/a><\/li><\/ul><\/li><li><a href=\"#A_Friendly_Checklist_You_Can_Actually_Use\"><span class=\"toc_number toc_depth_1\">7<\/span> A Friendly Checklist You Can Actually Use<\/a><\/li><li><a href=\"#Wrap-Up_Turn_Compliance_from_a_Fire_Drill_into_a_Habit\"><span class=\"toc_number toc_depth_1\">8<\/span> Wrap-Up: Turn Compliance from a Fire Drill into a Habit<\/a><\/li><\/ul><\/div>\n<h2 id=\"section-1\"><span id=\"What_KVKK_and_GDPR_Actually_Expect_from_Your_Hosting\">What KVKK and GDPR Actually Expect from Your Hosting<\/span><\/h2>\n<p>I like to think of KVKK and GDPR as two friendly but strict neighbors who care about the same thing: people having control over their personal data. GDPR covers the EU and EEA, and KVKK covers Turkey. The vocabulary is a little different, the paperwork takes different routes, but the spirit is similar. Keep data safe. Be clear about what you\u2019re doing. Don\u2019t keep information longer than you need. And when someone asks you to delete their data or hand it over, you should be ready.<\/p>\n<p>In hosting terms, there are a few roles that matter. There\u2019s the <strong>data controller<\/strong>\u2014that\u2019s usually you or your company\u2014who decides why and how personal data is processed. Then there\u2019s the <strong>data processor<\/strong>\u2014your hosting provider\u2014who handles data on your behalf. If the processor is outside your jurisdiction, or if your data is moving across borders, that\u2019s where localisation and transfer rules kick in. And that\u2019s where panic tends to start, because the internet doesn\u2019t care about borders, even if laws do.<\/p>\n<p>Here\u2019s my simple litmus test. If you can answer \u201cwhere your data sleeps,\u201d \u201cwho can see it,\u201d \u201chow long it sticks around,\u201d and \u201chow it gets deleted,\u201d you\u2019re already ahead. The rest\u2014contracts, documentation, technical checklists\u2014flows from those answers. You\u2019ll want a proper data processing agreement with your host, clear responsibilities, and a map of your data flows. Not scary, just systematic. And if you want to go deeper, there\u2019s helpful official guidance from both the <a href=\"https:\/\/www.kvkk.gov.tr\" target=\"_blank\" rel=\"noopener nofollow\">Turkish Data Protection Authority (KVKK)<\/a> and the <a href=\"https:\/\/commission.europa.eu\/law\/law-topic\/data-protection\/data-protection-eu_en\" target=\"_blank\" rel=\"noopener nofollow\">European Commission\u2019s GDPR portal<\/a> that can orient you without turning you into a lawyer.<\/p>\n<h2 id=\"section-2\"><span id=\"Data_Localisation_Where_Your_Data_Sleeps_Matters\">Data Localisation: Where Your Data Sleeps Matters<\/span><\/h2>\n<p>One of my clients once asked, \u201cIf my site is hosted in Frankfurt, does that mean I\u2019m safe for GDPR? And what about Turkish users and KVKK?\u201d Great question. Think of data localisation like choosing the neighborhood for your data\u2019s home. If most of your users are in Turkey, keeping the primary dataset in a Turkish data center can simplify compliance conversations and make latency better. If you serve EU users, hosting in the EU is a smart default because you avoid some transfer complexities. When you operate across both, you\u2019ll want to be intentional about where the <strong>source of truth<\/strong> lives and how copies move around.<\/p>\n<p>Under GDPR, transferring personal data outside the EEA requires appropriate safeguards\u2014things like standard contractual clauses or an adequacy decision. That\u2019s not a showstopper; it\u2019s a framework. With KVKK, cross-border transfers also have conditions, and approvals can be more procedural. In practice, many teams keep primary data in-region to keep things simpler and then use controlled, documented pathways for anything that leaves. I\u2019ve worked with setups where the main database sits in Istanbul, with a read-only replica in an EU region behind strict access rules, and a separate analytics stream that\u2019s fully anonymized.<\/p>\n<p>Backups add an extra wrinkle. If you\u2019ve ever wondered whether backups count for localisation, you\u2019re not alone. The short answer is yes, they matter. If the data is personal and it lives somewhere, it\u2019s in scope. That doesn\u2019t mean you can\u2019t back up across regions; it means you should document where backups sit, how they\u2019re encrypted, and how you\u2019ll handle deletion requests. If you\u2019re designing a multi-region layout, decide upfront what\u2019s allowed to cross borders and what must stay. I like to write this in plain language and keep it with the runbook\u2014makes audits and client questions a lot less painful.<\/p>\n<p>One more thing: content delivery networks and third-party services can quietly move data around for performance or filtering. Be mindful of your CDN\u2019s logging behavior and the location of their edges. If a service inserts cookies, captures IP addresses, or processes form submissions, that\u2019s personal data processing. You don\u2019t need to run from CDNs; just know what they log, where, and for how long, and make sure your privacy notice reflects the setup. The <a href=\"https:\/\/edpb.europa.eu\/\" target=\"_blank\" rel=\"noopener nofollow\">European Data Protection Board<\/a> publishes transfer guidance that\u2019s useful for reality-checking these decisions.<\/p>\n<h3><span id=\"How_I_choose_regions_in_practice\">How I choose regions in practice<\/span><\/h3>\n<p>In my experience, I start by mapping users and the legal footprint: Turkish audience, EU audience, or both. Then I pick a primary region that aligns with the bulk of users and the stricter obligations. If both are equally important, I\u2019ve had success running dual primary stacks\u2014one in Turkey, one in the EU\u2014with separate databases and a carefully controlled sync for non-personal or anonymized data. It\u2019s a bit more effort, but it keeps the transfer math clean and reduces overnight surprises when rules tighten.<\/p>\n<h2 id=\"section-3\"><span id=\"Privacy-Friendly_Logging_Keep_the_Lights_On_Without_Storing_the_Keys\">Privacy-Friendly Logging: Keep the Lights On Without Storing the Keys<\/span><\/h2>\n<p>Logs are like the black box on an airplane\u2014you don\u2019t think about them until something goes wrong. But with KVKK and GDPR, logs deserve attention upfront. Because here\u2019s the twist: IP addresses, device identifiers, and even certain error details can be personal data. The goal isn\u2019t to stop logging. The goal is to log smartly: enough to debug, detect threats, and meet audit needs, without collecting every piece of personal information you can possibly grab.<\/p>\n<p>When I set up logging policies, I start with purpose. What do we need logs for? Usually it\u2019s three things: reliability, security, and compliance. For reliability, you want to see request paths, timing, and error codes. For security, you want authentication events, access attempts, and integrity alerts. For compliance, you need audit trails that show who accessed what and when. Notice what\u2019s missing from that list: full query strings with sensitive data, raw user input, and long-term storage of IPs. That stuff can become a risk if it leaks.<\/p>\n<p>On web servers, I trim logging formats so they avoid sensitive headers and redact tokens. I also anonymize or truncate IP addresses when it won\u2019t hinder security work\u2014hashing, partial masking, or using a short-lived pseudonymous token often strikes the right balance. On load balancers and proxies, I keep only the fields we genuinely need to troubleshoot issues. And on application logs, I\u2019m careful to avoid dumping stack traces that include personal details. There\u2019s nothing like a \u201cPassword reset for [email] failed\u201d message sitting in plaintext logs to ruin your day later.<\/p>\n<p>Retention is where you draw the line in the sand. I like to set default windows\u2014say, 30 days for verbose application logs, 90 days for access logs, and a bit longer for security logs if there\u2019s a compliance reason. The exact numbers depend on your industry, but the discipline matters more than the digits. Shorter retention reduces exposure. If there\u2019s a reason to extend retention, document it and circle back periodically to see if it still applies. Automatic log rotation, immutability for security logs, and encryption at rest are part of the routine. And of course, strict access controls; only the folks who need logs get them, and the access itself is logged.<\/p>\n<p>Centralizing logs helps when audits happen. A lightweight SIEM or even a well-organized log aggregation system means you can answer questions quickly: who accessed admin at 03:17, how many failed logins triggered the lockout, when did the WAF block that IP range. Time synchronization across servers is one of those boring details that pays off when minutes matter. And if you ever handle a breach response, having logs that are reliable, tidy, and limited in sensitive data saves you from a second crisis during the first one.<\/p>\n<h3><span id=\"Web_database_and_security_toolswhat_I_keep_in_mind\">Web, database, and security tools\u2014what I keep in mind<\/span><\/h3>\n<p>On the web layer, I strip query parameters that include personal data from standard access logs and rely on targeted debug logs during incidents. On databases, I avoid logging full row contents; I focus on slow queries and schema errors. For security tools like intrusion detection and WAFs, I store enough detail to understand an attack pattern without keeping payloads longer than necessary. And if I must keep payloads briefly for analysis, I store them separately with tight retention and access limits. It\u2019s not about perfection; it\u2019s about balancing usefulness with privacy.<\/p>\n<h2 id=\"section-4\"><span id=\"Deletion_and_Retention_Policies_Making_the_Right_to_Be_Forgotten_Real\">Deletion and Retention Policies: Making the Right to Be Forgotten Real<\/span><\/h2>\n<p>Let\u2019s talk about the least glamorous topic that causes the biggest headaches: deleting data. I remember a startup founder who swore they were deleting customer data \u201cinstantly.\u201d We traced the data and discovered it was disappearing from the main database but living a whole extra life in three backup tiers, analytics snapshots, and a staging copy. That\u2019s normal. Data scatters. The trick is to make deletion a process, not a wish.<\/p>\n<p>I always start with a data inventory. Nothing fancy\u2014just a clear list of what personal data you collect, where it\u2019s stored, who has access, and how long you plan to keep it. Then I define retention by category. Maybe transactional data needs to stick around for financial or legal reasons for a while; maybe support chats can be shorter. What matters is that you decide. You\u2019re allowed to have practical retention periods as long as they\u2019re justifiable and documented.<\/p>\n<p>For operational deletion, I like a two-step path. First, soft deletion in the app so the user no longer sees their data and it\u2019s excluded from active processing. Second, hard deletion from primary storage on a schedule that\u2019s short and predictable. When it comes to backups, the approach changes. You rarely surgical-delete a single user from a snapshot; instead, you set backup retention so older snapshots age out. That\u2019s acceptable, as long as you stop using the data for any purpose and ensure it disappears when the retention window closes. If you need a refresher on building a sane backup framework, I\u2019ve written a friendly guide to the <a href=\"https:\/\/www.dchost.com\/blog\/en\/3-2-1-yedekleme-stratejisi-neden-ise-yariyor-cpanel-plesk-ve-vpste-otomatik-yedekleri-nasil-kurarsin\/\">3-2-1 backup strategy and automating backups on cPanel, Plesk, and VPS<\/a> that pairs nicely with deletion policies.<\/p>\n<p>Verification is the part people skip. When a deletion request comes in, I want to be able to prove that the data is gone from primary systems, queued for removal from caches, and set to expire from backups according to retention. I keep a simple checklist and record on the ticket the exact time the deletion job ran, which systems were touched, and the expected final backup expiry date. If we anonymize instead of fully delete\u2014say, for analytics\u2014we document how that anonymization is irreversible.<\/p>\n<p>One more practical note: secure wiping. For SSD-backed systems and cloud storage, you often rely on cryptographic erasure rather than overwriting blocks. Encrypt data at rest with keys scoped per environment, rotate keys when appropriate, and if you decommission disks, follow your provider\u2019s destruction process. You don\u2019t have to reinvent this; you just need to know how it works in your stack and be able to explain it in plain words if asked.<\/p>\n<h3><span id=\"Handling_special_cases_without_losing_your_mind\">Handling special cases without losing your mind<\/span><\/h3>\n<p>Sometimes a user has open invoices, or a fraud investigation is underway, or you\u2019re subject to a legal hold. That\u2019s life. In those cases, I mark the data as locked for a specific reason and restrict access. The key is that it\u2019s intentional. You\u2019re not \u201ckeeping it just in case.\u201d You have a clear purpose and a clear end date. And when the hold lifts, the deletion flow continues without manual heroics.<\/p>\n<h2 id=\"section-5\"><span id=\"Proving_Compliance_DPIAs_Audits_and_the_Paper_Trail_That_Saves_Time\">Proving Compliance: DPIAs, Audits, and the Paper Trail That Saves Time<\/span><\/h2>\n<p>Everyone loves servers until the first audit. Then you realize the quiet hero is your documentation. Don\u2019t worry, I\u2019m not talking about 90-page PDFs nobody reads. I mean a tight set of living docs and logs that show you know your system. In the KVKK and GDPR world, that looks like a simple record of processing activities, a data flow diagram, a list of processors and sub-processors, and your retention schedule.<\/p>\n<p>If you introduce a high-risk processing activity\u2014say, large-scale profiling\u2014you might need a Data Protection Impact Assessment. Even when it\u2019s not mandatory, doing a mini-DPIA is useful. You list the risks, the mitigations, and the residual issues you accept. It\u2019s less about creating a binder and more about proving you thought things through. When I walk a client through this, we keep the language human: what data comes in, what we do with it, who sees it, how it leaves, and how we protect it.<\/p>\n<p>Incident response is part of this story. You\u2019ll want a clear playbook that says who does what when a breach is suspected, how you contain it, how you notify affected parties if needed, and how you preserve logs. The irony is that privacy-friendly logging actually makes incidents easier to handle, because you\u2019re not drowning in sensitive details that complicate containment.<\/p>\n<p>Your hosting provider\u2019s role shows up here, too. Make sure you know how they handle security incidents, what their SLAs look like for notifications, and where your responsibilities start and end. If they offer features like DDoS protection, WAFs, managed backups, or regional replication, fold those into your controls and document the settings you\u2019ve chosen. The goal is to be able to answer \u201cHow do you know?\u201d with something better than \u201cBecause I think so.\u201d<\/p>\n<h2 id=\"section-6\"><span id=\"Practical_Hosting_Setups_I_Like_for_Compliance\">Practical Hosting Setups I Like for Compliance<\/span><\/h2>\n<p>Over the years, I\u2019ve found a few setups that cover most use cases without making you feel like you\u2019re juggling chainsaws. For teams focused on Turkey-first operations, a primary stack in a Turkish data center works well, with encryption at rest, a measured logging policy, and a clean backup and deletion plan. If you\u2019ve got a European footprint, mirror that idea in the EU and think carefully about whether you really need cross-region replication of personal data. Often, you don\u2019t.<\/p>\n<p>I also like to separate \u201chot\u201d personal data from \u201ccold\u201d operational data. Customer profiles and orders live in the primary database, and we keep them tight. Aggregated analytics, de-identified logs, and performance metrics live in separate stores. That way, your localisation and deletion policies are easier to apply, because you don\u2019t have to fish personal data out of a sea of telemetry every time someone asks for erasure.<\/p>\n<p>For keys and secrets, use managed key management or a well-audited vault solution and restrict access by role. Treat staging and development as real environments: either anonymize or use synthetic data. I\u2019ve seen too many teams leak personal data into staging and then forget it exists. If you must use real data in lower environments for debugging, set a very short retention timer and a deletion job that doesn\u2019t rely on memory or goodwill.<\/p>\n<p>DDoS protection, WAFs, and good old SSL\/TLS are table stakes, but for compliance they also help define your controls. Proper TLS settings protect data in transit, WAFs reduce exposure to injection attempts, and DDoS controls preserve availability\u2014which is part of integrity and confidentiality. Pair that with a firewall policy that defaults to deny and opens only what you truly need. Minimalism is a security feature.<\/p>\n<h3><span id=\"A_note_on_vendor_choices_without_naming_names\">A note on vendor choices without naming names<\/span><\/h3>\n<p>You don\u2019t need a \u201ccompliance-branded\u201d hosting plan to get this right. What you need is clarity: where the provider\u2019s data centers are, what logging they do by default, how backups are stored and encrypted, and how they handle deletions on deprovisioning. Ask how they support cross-border transfers, whether they have EU and Turkish regions, and if they\u2019ll sign the right processing agreements. Most solid providers have these answers ready. If not, that\u2019s your signal.<\/p>\n<h2 id=\"section-7\"><span id=\"A_Friendly_Checklist_You_Can_Actually_Use\">A Friendly Checklist You Can Actually Use<\/span><\/h2>\n<p>Let\u2019s keep this simple and conversational. Start by mapping your data. Where do you collect it, which services touch it, and what\u2019s the minimum you truly need? Next, pick your primary region deliberately and document why. Then shape your logs so they\u2019re useful without being nosy, and give them a retirement date. Build deletion as a routine, not a drama. And finally, keep a short set of documents that prove you have your act together: data flows, retention schedule, processor list, and incident plan. That\u2019s it. No wizardry.<\/p>\n<p>If you want to sanity-check your cross-border reasoning, spend a few minutes with the official pages from the <a href=\"https:\/\/www.kvkk.gov.tr\" target=\"_blank\" rel=\"noopener nofollow\">KVKK authority<\/a> and the <a href=\"https:\/\/commission.europa.eu\/law\/law-topic\/data-protection\/data-protection-eu_en\" target=\"_blank\" rel=\"noopener nofollow\">European Commission<\/a>, and keep an eye on transfer guidance from the <a href=\"https:\/\/edpb.europa.eu\/\" target=\"_blank\" rel=\"noopener nofollow\">EDPB<\/a>. Don\u2019t worry about memorizing every clause; just make sure your hosting setup matches the spirit and you can explain it in plain words.<\/p>\n<h2 id=\"section-8\"><span id=\"Wrap-Up_Turn_Compliance_from_a_Fire_Drill_into_a_Habit\">Wrap-Up: Turn Compliance from a Fire Drill into a Habit<\/span><\/h2>\n<p>When I think back to that client with the tight deadline, what saved us wasn\u2019t a magic tool. It was simple, honest answers and a tidy setup. We picked a primary region that made sense, trimmed the logs, tightened access, and wrote down how deletion worked\u2014including backups. Nothing flashy. But when the enterprise partner asked questions, we had calm, clear responses. That\u2019s the feeling I want for you: confident, not defensive.<\/p>\n<p>If you take one thing from this, let it be this: compliance isn\u2019t a finish line you cross once. It\u2019s a habit you bake into hosting\u2014where data lives, what you log, and how you let go. Start with the basics, adjust as you learn, and keep your documentation just good enough to help future-you. And if this sparked ideas or you want me to break down a specific setup, I\u2019m always up for another coffee-fueled deep dive. Hope this was helpful! See you in the next post.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>So there I was, coffee cooling on the desk, staring at a ticket from a client who\u2019d just landed their first big enterprise deal. \u201cWe need to be KVKK and GDPR compliant by next month. Can our hosting handle it?\u201d I could hear the mix of excitement and panic in their voice. If you\u2019ve ever [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":1296,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-1295","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/1295","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=1295"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/1295\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/1296"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=1295"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=1295"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=1295"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}